Regarding the issue of the schema name: as Tony says in simple cases this
could probably be hidden, however there are good reasons why we may want
to provide access to (hence expose) the schema name in ADQL queries.
One case is where a single service provides access to tables in multiple schemas within the DBMS; if the service provides access to many tables, this provides a useful way to organize the data. One could argue that each schema should be exposed as a separate service, however this would prevent use of any ADQL operations which combine data from multiple schemas.
Another possible use-case involves how we integrate a local VOSpace into TAP. A logical way to provide a VOSpace local to a DBMS is to implement the VOSpace with a schema (or "database", depending upon what terminology you use). Externally this would be seen via the VOSpace API, but internal to the DBMS it could be seen as a separate schema, e.g., "vospace". If tables input to the VOSpace are stored internally as tables (as they may eventually have to be to be used in a query), they would be usable directly in ADQL queries by the TAP service, in combination with ordinary data tables such as read-only catalogs within the DBMS.
The tableset metadata for such local-VOSpace tables could be queried either via the VOSpace API or via the TAP service directly. In TAP_SCHEMA.tables for example they would show up in the list of tables, with schema_name = "vospace" (or whatever). A DBMS already allows all this to be done on a per-user basis using the DBMS security mechanisms, so the user would see only their data or public data; an unsecure TAP service would see only public data.
A similar mechansim could conceivably be used for a small table uploaded in-line as a VOTable in a POST query, as for the multi-region query case.
Also - while VOSpace integration is an advanced capability, we have already established that it is a high priority for TAP. Schemas might not be the best way to handle integration of a local VOSpace with the DBMS, but it is worth considering. It would seem to be a good way to leverage the existing capabilities provided by a modern DBMS.
I'm still trying to figure out if we really need CATALOG_NAME. This is NULL or undefined for some DBMS implementations (MySQL and Informix, so far as I have been able to check), and in other cases appears to be fixed for a runtime DBMS context (PostgreSQL, possibly MSSQL).