Good stuff here :)

If they introduced a formal, parameter node type (BB currently uses Math and Simple color nodes for parameter nodes) or even just a formal naming convention for these, then it would be relatively trivial to write a UI engine that builds a form dynamically, for the end user, I would have thought.

I say relatively... that's relative to human resource, I guess.

Add to that a group node, as also suggested here, and perhaps a presets node, that stored an array of preset arrays, for the UI engine to read in from.

Everything there can still be stored in an mt5 format, or mc6 collection format even?

However, maybe the nodes are redundant?

These are just visual representations of shader definition objects...

If the real mat room gurus are happier just working with an object-oriented script interface, to compose materials, and everyone else just wants the form-based UI...maybe we don't need the nodes?

I do have to say, at the stage I'm at, at least, I think I still find them more intuitive to work with than pure script. But at times I suppose they probably also just obfuscate things for me too...

...looking at a matmatic script, which BB has posted in a thread, which pares everything down, has quite often made it all much clearer for me...

...relatively ;)

Certainly... pretty sure I'd still I understand a lot less about materials if all I'd had to work with from the start was an array of EZSkin-like wacros.