Indeed, I recently modified the way some information about tables was returned in order to have more precise values. In particular, the number of records info may be long to retrieve on some large tables. However, this happens only when a fast way to get it is not possible. Normally, retrieving this info is fast for all fixed record size table types (FIX, BIN, DBF,and VEC)
It is also fast for variable record length tables (DOS, CSV, FMT) when they are indexed because the table size can be retrieved from an index. The only long case are variable record length tables when they are not indexed.
For remote tables, to get the number of records info, CONNECT sends

select count(*) from remtab

to the remote server and some ODBC data source have not a fast way to return that (before, I was just returning 10)
Now, to handle your problems, I must have some examples of INFORMATION_SCHEMA queries that take a long time to be sure to find when and where there is a performance issue to fix. Then I could for instance add a CONNECT global variable allowing to tell whether or not one needs to have exact values when querying for table info or if just an estimate is enough.

The 1st query that burned us looks at the information_schema to see if any of our source or target tables have changed since the previous ETL cycle, and will require our dynamic stored procedures to be rebuilt. Because of the nature of the join, it requires every row from "tables" to be returned, and I believe MariaDB is executing the "select count" for each row.

select ds.base_cdc_name, ds.cmd_line_args, ds.destination_table

  from util.deploy_specs ds

       join information_schema.tables inf

          on (ds.destination_table =

                 concat(inf.table_schema, '.', inf.table_name))

 where     ds.last_change_to_destination_ddl < inf.create_time;

Although we no longer have 10.0.13 installed, I believe any query that retrieves a row from "tables" will trigger a "select count", even if I'm not interested in the rowcount of the table. I know the query below was extremely slow before we downgraded to 10.0.12.

select table_schema, table_name, create_time from information_schema.tables;

I understand the desire to return more accurate results, but indiscriminantly running a "select count" seems dangerous from a performance point of view. You don't find many articles on the web that discuss data warehousing and MySQL, so maybe the kinds of large tables that I deal with are a rarity in the MySQL community. Still, even if you have a lot of small CONNECT tables, a bunch of "select count" calls could add up.

I'd argue that reaching out into a remote database at all for an information_schema query (even when querying the index) may be undesirable. Many companies are moving portions of their infrastructure to the cloud, and the way you make the costs work is by shutting down servers when you don't need them. I know when my remote servers are available and can schedule my ETL processes to query those servers at the appropriate times. But if I look at the information schema when the servers are down, the queries will presumably hang and time out after a while.

I suppose I'm coming to this from an Oracle background, where similar functionality is achieved using database links, and calls to remote databases are not made unless you specifically query them. Table statistics from the system tables are normally cached from prior analyze statements and are usually only estimates.

A workaround could be for me to move all CONNECT tables into their own schema(s), and explicity skip those schemas when querying some on the information_schema tables. I'm not sure if adding a "where table_name != 'my_connect_schema'" would alleviate the problem.

I have added a new CONNECT global variable connect_exact_info. One can set it by:

set @@global.connect_exact_info={ON | OFF};

It is OFF by default meaning that the new version will behave like 10.0.12 and can be set to ON to work like 10.0.13.

Thank you--this will do the trick.