Replacing application-internal data structures with some data warehouses has a long history.
Once it was in-memory ISAM tables with manual sorting/indexing
As CPU/memory increased, solutions like generic SQLite(having 'in-memory' mode) or language-specific NexusDB/sqlMemTable appeared.

Latter has drawback that when new Language version is rolled out they usually lag behind for quite a while.
SQLite is popular, but not as feature-rich as FB and language-specific access components might be worse for some languages (especially Delphi lineup) than for FB.

However generally converting file-based database into memory-based would be too complex goal to worth doing/asking for. But not now, i feel.

Global Temporary Tables were introduced into FB quite ago. And with 2.5.1 release GTTs can be used fully even in generally read-only database.
So all the code for in-memory tables, indexes, views etc is in place already.
Metadata can't be changed but it arguably may appear 'right thing' for the in-memory database: not using 'db generator script' but using ready-made database file with ready-made data access components bindings, PSQL, etc. Also this aligns well with Windows restriction that in-memory file should have predefined length and never grow (if implementation would use file handles API for bootstrapping rather than fully separate file class, this easy way is okay probably, since 'tis only needed to read headers once on r/o database).

What i feel is left to be implemented:
1) database file opening from memory in FB Emb
1.1) either only-r/o databases
1.2) or every database, if opened 'in-memory' should be treated effectively r/o
All the actual work is to be shared between persistent VIEWS/TRIGGERS/PROCEDURES

2) bonus: UDF support in-memory. Not via extra files but again via function pointers
Nice thing, though not necessary, and can be done anytime later.

3) bonus: EVENTs posting via common connection stream (X-NETc in-memory stream for FB-Emb), rather than separate TCP connection.
This can start as FB Emb optimization (TCP requirement for an application to talk to itself is curious artifact) and later generalized into FB-generic enhancement (as done in IB7.1sp1).
While this may made diagnostic sometimes more complex, it would made system configuration a bit easier
This change can be done anytime later as well.

4) Lock logic. IF application tries to use 2-connections scheme, or application has plugins that might open there own connection to database - should there be locks ? Or should in-memory DB be forced to single exclusive connection ? Faking filename to something like "/\memory@12345ABCDpid1234/\" would probably warrant any currently possible filename still usable and Lock id unique enough to allow non-exclusive connections.