[Development] Multiple QML engines with different import paths, file selectors, etc

[Ulf Hermann]

> Hi, have you considered how you can keep compatibility, by making this 
> change either opt-in or opt-out? Since it seems the refactoring is 
> already done, it feels like you are making a bet that only has a 
> negative outcome for those porting/trying to keep up. 😊 Good for 
> maintenance, bad for users?

OK, I'm convinced. My experiments have unearthed lots of "interesting" 
behavior, but the basic example of having two engines with different 
import paths both load some document works. That is, the resulting QML 
types are indeed different. So I've dropped 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/527526 - the 
change that makes compilation units visible across engines. The 
refactoring for splitting the compilation units in a way that eliminates 
engine pointers from the global type registry is still a good idea, but 
it can be done without any functional changes.

The minimal fix for QTBUG-120189 is to double check the engine-specific 
type loader for any property type added to the property caches. This 
isn't pretty but it does the trick. See 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/529215

In the long run, we have to untangle this somehow. You can't have 
different types for the same document in different engines and _also_ 
store all of this in a global type registry that assumes you have a 
unique type for each URL. Currently this assumption is enforced in some 
places but deliberately avoided in others.

When we get qmltc and qmlcachegen into a shape where the code generated 
by qmltc can directly call the functions and expressions compiled by 
qmlcachegen we won't need much of an engine anymore if you exclusively 
run pre-compiled code. When running the QML code through the interpreter 
or JIT we might then duplicate the type registry for each engine and 
isolate the type registries against each other. Those could then be 
safely used with custom import paths, URL interceptors etc. That's still 
quite a way to go, though.

best,
Ulf