The next major version of Freebird (i.e. v3) will use a new internal architecture that's much easier to program with. In some ways, it's an evolution of the architecture used in Freebird v2, but taken to its logical conclusion.
The current version of Freebird (v2) uses a DOM-like model, and borrows a lot of programming patterns from browser-based programming. An underlying runtime abstracts away input events (like trigger_press, drag, enter, leave etc). It follows an event dispatch model (using add_event_listener and dispatch_event). Visual elements like menus, transform handles etc are DOM Nodes, which respond to events like drag and click. It also uses CSS-like styling to provide an easy way to style groups of related elements (like menu buttons).
This programming model was very powerful to use in v2, and allowed me to build a lot of functionality in a decoupled manner (which was a big problem in Freebird v1). New features like 3D grid, Camera Preview etc could be implemented as decoupled scripts that worked with a well-defined programming and event model. Scripts could listen to (or emit) higher-level events like cloned or moved and react to other scripts that emitted events.
But v2 didn't go far enough. It was inspired by the DOM spec, but didn't follow it strictly. It deviated from the DOM spec in a lot of areas and reinvented a lot of concepts (like custom versions of components, styling, UI elements, requestAnimationFrame etc). Often these deviations and reinventions were poorer designs.
This resulted in something that looked and felt a lot like the DOM, but would jarringly break the abstraction when dealing with some of the finer details. That broke the flow often when building new features.
Freebird's v2 has given me sufficient confidence that a DOM-style API for building 3D experiences (in an actual shipping, selling product) is productive and scalable. It's already way more productive and scalable than the spaghetti code of Freebird v1.
So Freebird v3 will take this to the logical conclusion, and use a subset of DOM and CSS, and follow the spec very strictly. Scripts will be loaded using script tags (executing Python instead of Javascript), reusable components will be implemented using Web Components, frame-by-frame processing will be done using requestAnimationFrame instead of a custom Unity-like update() method, and so on.
This will also make it easier to start writing plugins for Freebird, because it will use a mental model that's very familiar to a lot of developers.
There will be a very small number of additions to the DOM/CSS spec, in order to support 3D content and XR controllers. For e.g. native events for XR controller buttons, at par with mouse and keyboard events (instead of the verbose API of WebXR). But these additions will be kept to the bare minimum necessary.
Obviously this v3 redesign is not strictly necessary. I can keep churning out more features on the existing Freebird v2 platform. Infact I will continue doing that in the short term (i.e. adding more user-requested features in Freebird v2), while developing v3 in parallel. But I really believe in the importance of a better development platform for building 3D (especially XR) content, and I think there's a lot of potential in a Web-like development experience for creating 3D/XR content (remember JanusVR?).