I’ll leave a few thoughts here to elaborate on the comments I’ve left in other places before. I’m looking at this mainly from a software architecture perspective, but as far as I know these suggestions are fully compatible with the product requirements.

Use data type registration (not necessarily a new data type!)
Since this feature changes how item statement values behave, the existing data type registration mechanism seems like the right extension point to build this on. It was created to add new data types to a Wikibase instance, but it can also be used to override existing ones. From a technical perspective, I don’t think it makes a big difference whether we create a new data type, or override the existing wikibase-item type.

In either case, I think the result should be one data type that supports both local and remote items. Making properties support a mix of multiple data types as the question in the task description suggests sounds like a dangerous change.

Consider creating a separate extension
The biggest advantage I see in using data type registration is that it requires (almost?) no changes to existing Wikibase code. The whole feature can be implemented in a completely separate MediaWiki extension. I think that’s worth considering because it means:

• Lower risk to break Wikibases that don’t (yet) need this feature like Wikidata
• More freedom for the team working on the feature (separate repo, faster CI)
• A clear boundary between “core” Wikibase and this feature
• No need for a config-based feature toggle

Don’t use entity sources
Entity sources were initially created to enable structured data on Wikimedia Commons. I was part of the team that then built federated properties on top of entity sources, and we regretted that after a while, because it had a massive ripple effect throughout the code base.

Some kind of configuration will of course be needed for remote Wikibases, but that could go into a separate setting.

Don’t extend wbsearchentities unless necessary
The UI component suggesting a mix of local and remote items doesn’t have to use wbsearchentities. It’s probably cleaner to just create a dedicated (REST?) endpoint instead of modifying the existing search behavior.

Keep storage simple
As long as data storage of remote items is only needed to avoid repeated requests to fetch labels and descriptions, we can probably get away with a simple cache instead of storing that data in a dedicated db table.

Due to size converted from a Spike to an Epic of Spikes :) This will be split into sub-tickets which can be added to sprints individually.