Every layout is composed of one or more Ext.Container elements internally, and ContainerLayout provides the basic foundation for all other layout classes in Ext. It is a non-visual class that simply provides the base logic required for a Container to function as a layout. This class is intended to be extended and should generally not need to be created directly via the new keyword.

Ext overview has this which is worded a little better IMO:
[QUOTE]This is the base class for all other layout managers, and the default layout for containers when a specific layout is not defined. ContainerLayout has no visual representation

This is a layout specifically designed for creating forms. This class can be extended or created via the layout:'form' Ext.Container.layout config, and should generally not need to be created directly via the new keyword. However, when used in an application, it will usually be preferrable to use a Ext.form.FormPanel (which automatically uses FormLayout as its layout class) since it also provides built-in functionality for loading, validating and submitting the form.

Note that when creating a layout via config, the layout-specific config properties must be passed in via the Ext.Container.layoutConfig object which will then be applied internally to the layout. The container using the FormLayout can also supply the following form-specific config properties which will be applied by the layout:

The part in bold red is missing from the API and would be helpful:

The FormLayout is a utility layout specifically designed for creating data entry forms. Note that, in general, you will likely want to use a FormPanel rather than a regular Panel with layout:'form' since FormPanels also provide automatic form submission handling. FormPanels must use layout:'form' (this cannot be changed), so forms needing additional layout styles should use nested Panels to provide them.

The layout type to be used in this container. If not specified, a default Ext.layout.ContainerLayout will be created and used. Valid values are: absolute, accordion, anchor, border, card, column, fit, form and table. Specific config values for the chosen layout type can be specified using layoutConfig.

Proposed:

The layout type to be used in this container. If not specified, a default Ext.layout.ContainerLayout will be created and used. Valid values are: absolute, accordion, anchor, border, card, column, container, fit, form and table . Specific config values for the chosen layout type can be specified using layoutConfig.

Add in more background paraphrased from overview:

[QUOTE]Layouts are also managed by Ext so that size, position, scroll and other attributes. You can mix and match different containers, each with a different layout, nesting to any level you want.

Layouts are created and used internally by the container classes. Containers themselves know nothing about layout

Adds the ability for single level grouping to the grid so rows can be grouped on a given column, and regrouped by the user dynamically. Each group of rows can also have an optional summary row for summarizing the data in the group.

Mention link to the example/demo or show a code snippet example (entire example code below for reference .... clip out the extraneous?):

Use XTypes to optimize Component creation and rendering. Any Component can be created implicitly as an object config with an xtype specified, allowing it to be declared and passed into the rendering pipeline without actually being instantiated as an object. Not only is rendering deferred, but the actual creation of the object itself is also deferred, saving memory and resources until they are actually needed. In complex, nested layouts containing many Components, this can make a noticeable improvement in performance.

In the first example, the button will always be created immediately during the panel's initialization. With many added Components, this approach could potentially slow the rendering of the page. In the second example, the button will not be created or rendered until the panel is actually displayed in the browser. If the panel is never displayed (for example, if it is a tab that remains hidden) then the button will never be created and will never consume any resources whatsoever.

saJoshua you don't say why you think it should be shown or where it's listed in the docs now with the dead link?

Ext Team:

It looks like setDisabled is a method (not config) of Component.

Is this a problem with the jsDoc algorithm or how it's currently tagged? I say this because just before setDisabled is "//private". Keep going upward in the file and look at all the places it is marked "//private"....the next property afterwards doesn't show up in the docs even if it has description. So it appears the private tag is cascading down to the next properties??