As you know, uibuilder was always a base framework and there has always been the intent to build higher layers on top. I have done some very simple examples but more work would, of course be needed.
I based uibuilder on VueJS predominantly as this showed the most promise and greatest flexibility with minimal boilerplate. But of course, you can use any framework. Svelte, for example shows great promise.
So if someone(s) were to focus on the higher-level stuff and I focused on the lower-level, that would immediately give a broader development base.
So that is one possible approach. Build a higher-level framework over the top of uibuilder. That framework could itself be in two layers. A mid layer could focus on the components and I've already made some moves to make components easier to create and manage across multiple packages. The top layer could focus on the actual GUI builder.
My fear for Node-RED if you follow some of the other dashboard projects would be getting into the same position as you are now with a large, mostly monolithic core codebase only maintainable by 1 person.
Something like Appsmith or one of the other GUI builders might provide the top-level of a future dashboard of course which could greatly reduce future risks.
Whichever approach is taken, I would certainly advise ensuring that it is broken into different areas that can be more simply maintained.
I would say not, for the reasons given above. The current code, even after your own stewardship, is arcane, and complex. Code is passed around in ways that don't really fit in with modern web tooling or best practice which adds to the complexity of new components and leaves them tightly coupled to Dashboard making the move to a new generation difficult.
Yes! (But I would say that because it is how uibuilder is architected 
)
Decoupled components allow growth and change without destabilising the whole.
No! The editor is complex enough as it is. Also, I know that separation of the editor from the runtime is being looked at and further integration would surely inhibit that?
At the end of the day, Node-RED is a SERVER, a web Dashboard should be clearly a client. With Node-RED's excellent comms capabilities sat between the 2.
I don't know that you realistically have a lot of choice. You need to give support to component developers so that they don't have to do the whole DOM thing by hand otherwise every component will work differently and it will certainly never be performant.
Just don't chose one as arcane as Angular! My current favourites are certainly VueJS still. It is still growing and has fantastic and growing support. And yet it isn't overly complex either. If you want to do simple things, you can do them simply, without even needing a build step.
Also Svelte which I see has tremendous potential though is still quite young.
REACT of course must also be considered if only due to the breadth of support that it has (though last I looked Vue was growing faster).
For the same reason given above, I believe this would be a real mistake. A good front-end framework does the heavy-lifting in a consistent way but doesn't get in the way (one of Angular's faults). It uses best practices and benefits from a dedicated development input that continues to improve performance, and stability not just feature bloat.
A good framework is also modular, allowing change to happen in uncoupled ways.
