Ok - this is effectively what I've tied to do.

Somewhere there has to be an interface that links between the zwave configuration and association command classes, and the UI. This can be in a separate bundle if you would prefer, but there would still need to be some sort of exported interface that interacts with the binding in some way. Yes, this could be more "z-wave" like interface, but it still needs to be there, and we'd still have almost exactly the same functionality that I've got in the "config" package.

 
I think we're talking almost the same thing except I've put the implementation into a separate package within the binding, and you want to move it to another binding an implement another interface. Then it would be this new interface that is only supported by the zwave binding.

 
Don't get me wrong - I'm not against your idea, but effectively we're just adding another binding, and another interface and I think this gets messy when we apply this to lots of bindings (thinking ahead a little here).

 
I agree that 420 isn't agreed. However, my personal feeling is that all bindings should be self describing such that they can be administered. I believe that Kai also agrees with this concept in 420 (maybe Kai can comment here) although clearly there is much to be discussed regarding the final implementation :) It would be nice for all bindings to implement such an interface right now, but we need to start somewhere and I don't think that the fact that only one binding would support this is a good reason not to do it? I think that zwave needs to have a configuration interface, so why not start to implement such an interface here and get some experience with what's needed. It won't require major refactoring of the binding if (when) this interface is changed since the interface is contained within a single page. The "config" package in the binding would therefore need refactoring, but not the binding itself. The internal interface between the internal.config package and the protocol side of the binding is done in a very zwave way (ie through the command classes).

 
I think what I'm proposing is a reasonably pragmatic way that allows the binding and openHAB to evolve. It's difficult to describe these things so maybe a structure diagram would help? If you like, I can do this tomorrow - I'm about to head out to a show soon so probably haven't got time now...