Jimz1 - lots of posts on topic, and maybe some folks can post links to them here.

Here’s a summary -

During treg, we’ve received and accommodated a lot of requests for enhancements and extensions of features. The improvements have been very productive, handle many more use cases, and make the product generally more refined and just nicer to use.

As we added these changes, we approached the capacity limits of the system memory and cpu bandwidth.

Each new request for an update required an increasing proportion of coding time for organizing and allocating space, rather than the change itself. We reached a point where perhaps 80% of the work was just to first make space for the change.

Our team reviewed this, and also considered that these requests would continue, and would likely increase dramatically with the diversity of mass users in general release. TextBlade’s new software-based technology platform inherently invites higher expectations for what a keyboard can do.

We concluded that it was wise to find a wholesale solution that provided plenty of space to do whatever users might ask for. Central to TextBlade’s identity is that it’s a software platform, rather than just some soldered switches. So users have an expectation that you can make TextBlade do new things, much like a smartphone can with a new app.

We studied how best to do this, and found that a new firmware infrastructure could give us lots of running room to respond to new user requests, and to code it several times faster. The up-front investment in smarter infrastructure would actually save time overall, because of the relief from the code space burdens.

We resolved that it was wise to get this behind us before general release, so that supporting mass-install would be greatly simplified. We began working on this in parallel to our existing code releases last year, and have now gotten to a point where it will soon reach feature parity with the currently shipping product. We have working test releases in our labs, and will seed it to treg users once we have finished our internal validation.

There are many unannounced benefits of this new infrastructure fork, and we believe customers will be quite excited about them. The primary logic however, behind getting this done in advance, is that it’s a smarter way to manage the mass rollout. It would be quite difficult to bring everyone forward once there’s already lots more older-fork product in the field.

Tesla went through this very issue on their early releases of autopilot, and it was very complicated for them to provide concurrent updates to the many flavors of their platform. It is far more manageable to have everyone start on the same page.

So that’s why we chose this path. Less hassle for customers, and smoother rollout and faster advancing of the platform in the field. TextBlade is really a new software platform, not just a box of switches like legacy keyboards. So settling this foundation upfront is the wisest path.

We think you all will really like what this new infrastructure makes possible. To keep a tight rein on schedule, the rule for our dev team is - no new features until feature parity is confirmed, and we’ve begun general release. The currently shipping release is already far beyond the functionality of typical keyboards, so we don’t need to add features in order to start GR.

But strong foundation must be there to support what treg has proven - there will be predictable excitement, and much demand for extending the platform, once mass users experience what’s now possible with a keyboard.