The original Jenkins configuration model did not have an implementation ItemGroup for TopLevelItem instances other than the root node.

When the folders plugin was released, however, this changed... the configuration model of core did not.

There are lots of configuration options in the Jenkins global configuration where it would make sense to allow a hierarchical configuration model.

The credentials plugin had such a critical need for this that it contains its own home-grown implementation of a hierarchical credentials store (if this feature is implemented, then the credentials plugin could be refactored to use this for the ItemGroup based stores - more correctly the folders plugin could be refactored to store the folder scoped credentials in this ItemGroup configuration stores)

Other configuration elements where it makes sense to have hierarchical configuration:

• Tool installers - or at least Tool Installer mapping so that teams in one folder can call their JDK's jdk8 and jdk9 with java8 and java9 pointing to pure JREs while teams in another folder can call the exact same JDKs java8 and java9 respectively
• Maven / Ivy / Ant default project configurations
• Any of the server list types, e.g. SonarQube servers, S3 configuration, etc
• Any plugin that has default configuration for it's behaviour so that teams do not need global admin permissions to tweak the defaults within one folder... this includes both builders and notifiers... for example some teams may want all jobs in a specific folder to have the notification email sent with a different mail settings

The hierarchical nature would mean that plugins implementing support would need to define how inheritance works. Some plugins would be a merge model, some would be an append model, some would be a replace model.

• The list of things style configuration, e.g. servers, tool installers, etc... would all probably use some form of append... perhaps with parent levels being able to specify conflict resolution strategies (i.e. can a child replace an entry with the same ID from the parent)
• The default settings style configuration, e.g. things like build failure analyzer could either use the replace model or choose to allow fall through to the parent for configured values

The global configuration, or thinking hierarchical - any parent ItemGroup - should be able to control what parts of configuration have been enabled for child ItemGroup configuration.

Once an actual configuration storage API has been enabled, the next step is to get each plugin that is implementing the API to use that API to resolve its configuration. Experience from the Credentials plugin shows that it is a long road to get plugins to update their API usage