Cascading configuration means sharing common configuration
settings between similar variants of bootstraps. This allows multiple
variants, all using the same basic settings - no point writing the same
script multiple times to do the same thing for different setups. A
configuration file for multistrap could be defined as base
and another as variant. The variant declares an includes
field which specifies the base file to use for the rest of the settings.

Variant would include only those settings from [General] that differ
between variants and then a number of sections, like Grip, GripUpdate,
Debian, Local etc.

Base would include the core settings that don't change and maybe one
section for the base packages.

The current configuration files for pdebuild-cross use
cascading multistrap configurations to organise the various cross-building
toolchains with more general purpose package building support.

Settings from [General] in the variant would override those in base.
(i.e. the value in base is ignored and the variant used instead.)
Lists in [General] in the variant will append values from lists in base.
Sections in the variant would replace those defined in base, if any.
New sections in the variant would be put alongside those in base.

The variant file would need a new config key: Include: /path/
where /path/ is an absolute or relative path to the base config file
(relative to the location of the variant config file).

A Variant file could act as a Base file for another config, under the
above rules but I won't recommend nesting any deeper than that.

i.e. the cascade starts with the specifics and gets more general. This
allows the variant to decide which base files to include, rather than
trying to embed logic into a base file that could be included by many
variants.