Concurrent use of multiple Firebird embedded versions #1233

Not sure if you're still actively supporting .NetFramework but I have a couple of issues when accessing Firebird embedded databases in my BlackbirdSql DDEX and SqlEditor extension. I have built-in support for Firebird 2, 3, 4 and 5 embedded databases.

NativeHelpers _cache Dictionary
Whenever I access different versions of embedded databases a have to preemptively change the fb_dsql_set_timeout value in 'FirebirdSql.Data.Common.NativeHelpers._cache' dependent on the database version 2, 3, 4 or 5 to false, false, true or true respectively.
If I don't do this I get entry point exceptions.

Loading sequence of Embedded Database Versions
Also, I have to ensure embedded versions are initially accessed in the order Firebird 4/5 then Firebird 3 otherwise I get EngineXX exists but could not be loaded.
So if I initially access a version 2 embedded database I first have to open dummy embedded databases for version 5 and then 3 to ensure FirebirdClient internal variables are set correctly.
If I initially access a version 3 embedded database I first have to open a dummy embedded database for version 5.
If I initially access a version 4 or 5 embedded database I do nothing, but if I subsequently access a version 2 database, I first have to open a dummy embedded database for version 3 to maintain the sequence.

Access violations on Concurrent OpenAsync Requests
When both an Open() on the UI thread and then an OpenAsync() call are made to the same database within the same timeframe (< 10ms), the async process seems to modify variables that the UI thread is still using before it has completed.
The access violation occurs at FesDatabase::Attach() [183]

I have tested switching Visual Studio's Open() to asynchronous but it made no difference. I am assuming some of the variables used during an attach are not thread safe.
ATM I am switching the async tasks over to the UI thread before making an OpenAsync() but I would prefer not having to do this because there are other deadlock implications.
I have not been able to replicate the issue using Firebird 2, 4 and 5 embedded databases even though the logic and timing of multiple Open() tasks seems to follow exactly the same path when using these versions, but I cannot be sure it cannot occur.

If you have some time I would appreciate if you could have a look into these issues.

Thanks.