I hope this is the correct place to report this..

One of the pain points with MySQL for me has always been the storage architecture.
There is one huge "data directory" for all databases.
With innodb_file_per_table it is possible to have one file per table.. but still, these files are hardly usable outside of their original data directory.
If something in the data directory is corrupt, you have a problem.
If you install a new system, possibly with a different version of MySQL / MariaDB, simply copying the data directory is not a trivial task.
If you want to sync a project (e.g. a website) from one server to another, you need to work with dump files. You cannot just copy around the actual data files.
And you cannot store the database within a project directory - it has to be in the system's centralized "data directory", e.g. /var/lib/mysql. (you could use symlinks, but this feels hacky, because you need to move the files and create the symlinks after the db files are created)

Not all database engines work this way. E.g. sqlite has separate database files that can be copied around.
But for most projects I prefer to stick to MySQL (or something equivalent like MariaDB), because I am used to it, and because the tools I use (framework, CMS) are all tested and proven to work with it.

I think most of the features of MySQL/MariaDB that are required by a typical client app would work just as fine with alternative storage models.

I have not worked out any details, I simply would like to start a discussion / brainstorming.