We didn’t make it into an official fork mostly because of the license but also because the LXD UI was my first go at thinking about what a UI for a platform like LXD should look like (back when I was leading LXD at Canonical).
That initial UI design effectively came before any of those features were fully implemented or adopted:
- Clustering
- Virtual Machines
- Projects
- OCI containers
- Fine grained access control
- API metadata
- Advanced network features (forwards, load-balancers, zones, interconnects, …)
Doing it fresh now would come with all of those in mind from the start would most likely lead to a pretty different structure and set of priorities.
As mentioned by @bensmrs, there is some potential funding that may come from NLnet down the line to help bootstrap that effort. I’m also hopeful that FuturFusion and Zabbly will also be able to contribute time and/or funds to help with this.
Most of us are pretty low-level developers who may have a lot of opinions on how we’d like a UI to look like but aren’t web developers and designers, so making it happen will need some extra folks with a different skillset 
I suspect we’ll see the beginning of that work in 2026. As with any new project, it’s best to start with a pretty tight team at the beginning while the general structure and technology selection happens, then once the overall structure and processes are sorted out, parallel work will be much more feasible, effectively building up a long list of features that need implementing as Github issues and then letting everyone loose on that 
As @bensmrs mentioned too, we can’t really cut over to a new code base until we have at least rough feature parity with the current LXD UI fork. Given the LXD UI has taken a solid 5 years + to be built by now, by an active team of 2-3 developers. I expect that it will take us a solid year at least before we have something that’s complete enough to start putting in front of users.