I doubt there is any need for a new closed restricted forum.
I agree. This forum is a great place to discuss high level questions, and lower level details as well.
But speaking of high level questions, that's not the hard part: those are easy to ask and get answers, especially given that people naturally express themselves. High level issues, like whether or not somebody prioritizes georegistration, tend to be pretty clear, both in this forum and in suggestions.
Details like the specific sequence of clicks or keystrokes or whatever are the commands to denote or edit a control point, or where that falls in the workflow, are more difficult to determine. I think the forum is great at that as well, if the community is given something specific to evaluate. That's where the work and time savings come in, because it makes both immediate tuning/correction as well as the next iteration more efficient.
In many complex issues the devil is in the details, which often you don't even see until the thing is done to the point it can be used in real life work. What sounds great at the high level may be super or may be awful based on the implementation of details. Just a few small differences, like when and how you pick a field that's the target of an operation, can determine whether the workflow feels easy or seems clumsy.
In some cases, no matter how good you are at anticipating wide ranges of workflow and how they intersect with a very wide range of user skills and preferences, it's hard enough to construct specific implementations, in dozens or hundreds of small details, that are worth trying by a wider community. And even then, what you sometimes find is that what seems OK for the first dozen hours of use gets on your nerves after the next 20 hours of use.
That's the point of having cutting edge builds, because they provide an opportunity for worldwide assessment in situations where no amount of mockups, focus groups, discussions about one way or another, or other advance work tells you whether some change is good or bad.
Or, as is more often the case, what parts of a generally good idea need to be improved so the whole thing isn't just "good enough" but is felt to be an especially good step forward. Manifold puts a lot of effort into real life testing of variations on new approaches before they come out in a cutting edge build, so what gets presented for worldwide assessment by the community isn't going to be truly awful and waste everybody's time. The company is also willing, even towards the tail end of an iteration, to say, "no, not good enough, must be improved here and here," even if that means a significant amount of additional work.
It's true that such an approach, spending a lot of effort so something real can be presented for assessment by the whole community in a cutting edge build, is costly both in engineering resources and calendar time. But it does provide a reality check and real world guidance that cannot be beat.
Considering where the original beta builds started, we've already had 3 or 4 significant iterations of interfaces for select and transform functionality. All were based on high level guidance from users, and all have benefitted from community guidance and from new capabilities made possible by improved internal infrastructure. This next iteration will also be a step forward, based on high level guidance from the community, and it too will benefit from tuning based on real life assessment by the community. It too won't be the last iteration. All that is a lot of work, both for Manifold and for the community, but that's what you have to do when you want ever faster, smoother, easier, more efficient and more powerful workflow in complex settings.