Deeply-nested component material can become very "pointy" very quickly - 33% of this depth is accounted for by the extra layer named "options" which is necessary when a component's options are specified at the subcomponent level. Here is an example:

    fluid.defaults("fluid.prefs.prefsEditorLoader", {
        gradeNames: ["fluid.prefs.settingsGetter", "fluid.prefs.initialModel", "fluid.viewComponent"],
        components: {
            prefsEditor: {
                priority: "last",
                type: "fluid.prefs.prefsEditor",
                createOnEvent: "onCreatePrefsEditorReady",
                options: {
                    members: {
                        initialModel: "{prefsEditorLoader}.initialModel"
                    },
...

The initial historical driver for this was the "container" argument which was the 0th argument in the construction signature of viewComponents. Since this was manifestly not part of "options", a new level of containment needed to be created, when using declarative configuration, to house this argument. The other natural member of this layer was the component's creator function name itself, which became encoded as "type".

We may shortly be in a position to do away with this layer. Part of it has been inherently logically problematic - the "createOnEvent" annotation is used to describe the conditions under which a component should be created. This would seem to be impossible to move into the component's own options area, since evaluating this would seem to imply that the component must exist already. However, with the mind-bending possibilities resulting from the "globally asynchronous ginger world" described under FLUID-4982, this should become perfectly feasible.

The complete set of "top-level options" which would then be folded directly into options would be:

container
type
createOnEvent
priority (this should be renamed as "creationPriority" or abolished entirely)