Using embedded (in-process) engine has a muber of cons and pros. It might easy the deployment, but it also provides for application crash destroying the database.
For FB 1.x and 2.x application developer could specify his intention by selecting client DLL/SO
Since FB3 there seems to be no separate client DLLs released for embedded and standalone servers.
Many develoeprs foreseeing transition to 3.x asked how to ensure one of those modes to find there is no standard way and they should bind their application to FB 3.0 implementation details instead.
A requirement to use standalone server to an extent can be manifested by specifying inet:// or wnet:// pseudo-URI. But not with local (net) connection string.
A requirement to use embedded server can not be manifested at all.
So to specify the connection method there is a need for standard options ( made as a pair of pseudo-URI or better a parameter ) for the connection string that would specify application's requirement to use either embedded server dll in its own process or a standalone (not-embedded, independent) server process.
By option being standard it is meant that it would be documented, would be forward-compatible (until breaking changes would become required should work with FB 4.x, 5.x, etc) and should not be dependent upon leaking implementation details ( specific dll names that are subject to change, presence or absence of dlls in FB installation, specific hacks in firebird.conf, etc).
It should be an option that applicaition can set in a standard predictable future-compatible way without making any assumptions about FB version (except being 3+) and installation details.
Of course connection strings like "inet://localhost:3052/c:
\temp\db.fdb?isolation=in-process" would result as connection failure as tere is no plugin that would be both embedded and TCP-connecting. That is okay, explicit error it is better than hidden change in behavior.
Similarly "c:\temp\db.fdb?isolation=standalone" would most probably use xnet connection.
And mere "c:\temp\db.fdb" would leave the choice to the server's preferences and ability to lock database file by th application process.
PS. I hope that there would be 3.0.x or 3.x build that can implement this relatively isolated feature, as waiting two more years for 4.0 just to recover a minor connection-level feature from 2.x seems a bit long.