Burr wrote: "Rhino "Redoing it's mesher", in it's current, "overbloated" state, is going to be, quite possibly, an impossible task"

Sorry Burr, but I doubt this statement holds much water. There have been two alternative meshers developed recently, one from Tsplines (which overrides the default mesher) and another one from McNeel. McNeel could build another new mesh system and have an option to use either the new one or the old one as default until all the kinks are worked out. I expect that's how they will handle it, so nobody has to worry about breaking stuff in the process... Also I would like someone to point me to a truly good example of overbloating, something other than the huge # of available commands. The discussion has come up many times and there are always good reasons why the seperate commands should remain in place. The best reason is that one can quickly access a specific command by the keyboard and not have to click through options they don't need. options can remain sticky for that particular method. When you have to repeat a function many times; this is a blessing, not a curse... I do agree that Rhino needs more command consolidation, but again it goes back to what i just mentioned before. Many users don't want the specific commands removed. And it would be quite easy for a scripter to create a single uber-command which analyzes the type of input objects and then calls up the standard Rhino command to handle that particular case. This is something I've already suggested, and i may do it myself at some point for commands such as Booleans... If the claim of overbloating has to do with the UI, it's well known that Rhino V5 will have a new one. Not sure what that will look like but it's happening. But I hope it looks and works like Grasshopper's UI which is already very nice! :) So I doubt anything is really "impossible"...

Sorry for the OT... :)