Awesome; thanks for such a detailed update! Can you give details on the query-over-multiple machines risk and what could cause it? I have no wish to respond to people going out of their way to prevent us breaking things by, ah, breaking things ;).
Firstly, you'll only really risk breaking your own things; all this should be fairly insulated from the rest of the cluster. It also shouldn't require much extra thought when writing queries, except to use specific databases or tables if asked to do so :-)
I mentioned the MariaDB 10 CONNECT engine uses Engine Condition Pushdown. That's something that was developed some years ago when NDB, the MySQL Cluster engine, was being integrated, done to improve performance on the network.
The conditions in a query -- the WHERE clauses -- are sent to the storage engine by the SQL optimizer before query execution starts. If the engine supports ECP it can often pre-filter data before returning it to the SQL layer, resulting in less overhead, less data moving around, smaller temp-tables, faster sorts, etc. It's particularly useful when indexes are not necessarily optimal for ad-hoc queries.
If db1047 has a CONNECT table referencing a remote table on dbstore1002, then some or all of the conditions filtering that table will be executed on dbstore1002, while other tables and joins occur on db1047. It means shipping some data over the network, but hopefully not too much, and usually no more than any sharded/clustered/nosql solution.
CONNECT won't be a magic bullet, but it's an option that doesn't require significant redesign on any layer, and was designed for OLAP work.