Looks more like a GUI bug rather than a “disagreement”. Obviously the goal is to have it all pretty-generated by default.
Yes the goal is to be able to support a “good default” widget for every supported procedure argument, and variants for when the defaults are not what you were aiming for.
Resources is the parent class for brushes, patterns, palettes, fonts, etc. It’s not a class you can instantiate (you can only instantiate a subclass). Also I don’t think it makes sense to have a widget for “any kind of resource”. At least I’d be waiting for a real use case brought by someone before starting thinking of what could be a good UI for “any resource”.
Selection is an actual image selection, which is a child type of channel, itself a drawable.
Any of the above to report as a bug?
Possibly. I’d have to look closer at it. You may report it and when we have time, someone can take time to check.
There is a gimp_procedure_new function which works fine and we use it for a bunch of core plug-ins.
I guess you mean that some choices would be sensitive or not depending on other settings?
It is completely possible. In fact, we do this in a bunch of plug-ins (grep gimp_choice_set_sensitive plug-ins/). In particular, it looks like the DDS plug-in has on-the-fly sensitivity changing. What we do is to connect a handler to the “notify” signal of the GimpProcedureConfig object. When the other settings (supposed to trigger a choice update) is the one which triggered the signal, then we update the choice list sensitivity.
Check config_notify() function in plug-ins/file-dds/ddswrite.c. You’ll see how we change some options of the “existing” item in a choice list depending on the “save-type” arg with gimp_choice_set_sensitive(). You can also see how we enable/disable whole widgets with gimp_procedure_dialog_set_sensitive() depending on other settings.
Since the config values are synced with the generated GUI, this allows on-the-fly settings updates very very easily.
It was planned for 3.0.0 (in fact you were in the discussion, I see! 
). I was hoping to think of a powerful API to tell core when a plug-in should be active or not. It’s just that at some point, if we don’t want to release in 5 more years, we need to skim off a bit of cool new features. This was one of them.