I am not going to comment on any of the licensing/packaging points, as those are outside my area (I am the plugin’s developer, and happen to be in agreement with you on much of that). Regarding the plugin itself, indeed it is a bit of a stopgap, while we wait for the mac sdk to reach parity with the win sdk (esp. regarding RDK support), apparently in Rhino 6. I have already gone down the road once, of writing a lot of code to work around such missing things, and will wait this time to do things the “official” way. On the other hand, you may or may not have noticed that we start out this time with every parameter being implemented in terms of macro/script, since mac Rhino generates UI for commands. That’s good, but however functional it may be, the UIs are not exactly what I’d call nice when used to this extent, and it would be a mistake to think that custom UIs won’t be written for them.
Beyond this, though writing this plugin did involve wrapping the whole Maxwell sdk (c++) for access via c#, the fact is that RhinoCommon is not the only piece of the puzzle in flux; we have, for some time, been working on a new node-based sdk for Maxwell, which is much more modern and capable, and not weighed down with the baggage of a decade of ad hoc extension (understand, the current one was never designed to accommodate things like Maxwell FIRE, .mxx extensions, etc) and I don’t want to go too far down a dead end in the plugin with the old one. That is a big project, but I look forward to the time when I can build UI automatically in the plugin, and when you can play with Maxwell nodes in Grasshopper… so whatever the initial state of the plugin, those are some of the long-term goals.