May I suggest that we temporarily place Vlad's proposal on hold and go
back to where we should have started, which is with the requirements.

Good design really must start from a clear statement of the
requirements. Without an common understanding of the requirements, how
can we all know what we're trying to design, or whether a particular
design is insufficient or complete?

This isn't my design (I'm actually on vacation on my boat), but I'll
start the ball rolling. Pardon me if I state some of requirement as
questions.

I think the requirements for external database access are:

1. The ability to give a single SQL query that references tables in
more than one database.
2. Preserve standard SQL semantics for statements that reference more
than one database.
3. Preserve standard SQL cursors, including "current of cursor".
4. Preserve transaction ACID properties in transactions that
reference more than one database.
5. Preserve proper access control and security across various target
databases.
6. Permit reasonable optimization of cross databases and cross
network queries.
7. Provide transparency between various local and remote databases.
8. Works with the existing BLR client interface (quibble nor or lose
the right later!)
9. Works with the existing SQL client interface.
10. Works with the existing remote interface, server, and line protocols.
11. Works with the existing ODBC drivers.
12. Works with the existing JDBC drivers.
13. Transparent to clients.
14. Transparent to ODBC drivers.
15. Transparent to JDBC drivers.
16. Transparent to tools that use native Firebird system tables.
17. Tolerant of metadata skew when a remote database is altered
without notice.
18. Should all users of a external database table use the same account
and password?
19. Should access control to external database tables be defined at
the database level or (redundantly) at the external database table
level?

This a starting point. Other folks may want to add or remove from these.

There is always a trade-off between transparency and ease of
implementation. Where does it make sense to break transparency to
simplify impementation? For example, from before the birth of
Interbase, the table RDB$RELATIONS provides a list of tables within a
database and a join of RDB$RELATION_FIELDS and RDB$FIELDS generates the
list of fields within a table. For transparency, external database
tables should be described in these system tables as ordinary tables,
external file system tables, and views. This, of course, puts a burden
on the design. Alternatively, the requirement(s) for transparency could
be rejected and the burden shifted to the ODBC and JDBC drivers, client
tools, and any gateways. Or somewhere in between?