I certainly hope they do not add an ORM into WordPress. It would add a big layer of complexity and break nearly all plugins that interact with the database.

This can be mitigated by maintaining and updating both the database access as it is today as well as the ORM layer.

Which would probably mean some plug-ins using one and some the other. Perhaps over a long enough time scale converging for the ORM.

Right now debugging problems with the interaction between database and application are blessed by it being fairly transparent

Adding a messy layer in between adds complexity not worth it unless it is required to add support for many other databases and I dont see any reason why it would be beneficial for enough users for that to be worth it.

Introducing just SQlite will expose a lot of problematic edge cases. since MySql provides a lot of feature that Sqlite does not. (which in most cases is a very good thing)

I don't think this is a correct take, because most plugins that interact with the database already use the abstraction functions, eg get/set_option(), WP_Query, get_post_meta() and so on.

These would all work out of the box.

The only plugins that would not work are:

1. Plugins that register their own database tables (however there already exists prior art such as https://github.com/aaemnnosttv/wp-sqlite-db for handling these cases)

2. Plugins that do direct queries against the standard database schema (broadly either for invalid (bad code) or performance (valid but slim use case) reasons)

Also, WordPress would of course keep the old query functions around and they would likely add a tag to the plugin repository so authors can mark plugins as supporting thes new ORM features.

Great idea in my opinion!