i do want to support this, though probably not next release…
named parameter values - its a bit complex, one of my major aims for Kontrol is to allow remote control of patches - so I can control patches from other devices, like a Push 2, or from a computer via OSC. In this case, the remote control needs to know what the valid values are.
so the way I plan to do this is to create ‘enumerated values’ , these the underlying value will be an integer, but all possible values will be also supplied to the remote control, so it can display the possible values.
Im also wanting to do something similar with resources e.g. wave files… (e.g. im considering a ‘sample’ parameter type) … I really want a sample selection option to be ‘built it’ , perhaps even kits.
(the next release has ‘resources’ but Im only exposing in a very limited form initially)
Id also like a mechanism to allow a particular device to ‘render’ a page as it sees fit,
e.g. enable an ADSR, the values would still be sent, but a special page would be created where the controller could render it as it wants to (eg… graphically)
however, there would still be the option to fallback to the underlying numeric values.
(a bit like how a VST has a custom rendering, but you also get access to the underlying values, vital for automation!)
perhaps you can see from above, its a pretty complex area…
I could take the easy route , and say some patches can override this, and therefore be limited to working on the Organelle, but Im unwilling to do this - Ive bigger plans 
(that said, I might start getting Kontrol to notify the patch of the current page, so theoretically a patcher could just create an empty page, listen for this, and then render directly - however , this is not a practice I would encourage, or use on my own patches)
the passthrough is handled in the Organelle specific code, so if there are various types where this makes sense i could do it BUT honestly, I don’t like inconsistencies in UIs - so Id really like to see a patch/clear use case that shows that the passthrough is inconvenient, to the point that bringing in an inconsistent/new metaphor UI makes sense for the user.
overall - I definitely do want to make the UI more flexible , whilst still retaining a nice consistent UI, and also allow patchers to develop patches quickly (thats the thing Kontrol has quite a few ‘goals’)
… I guess in some ways im playing catch up, given we are starting to get some graphics patches now 
anyway, thats not for the next release, the next release is a pretty fundamental shift to patch development, so Id like to get that in place first (and its nearly finished ;)) , then we can turn to how to make the UI more flexible, to cover more patching needs.