Configurations have effect on suites, rather than to specific cases. That’s because an automation case can call Selenese function from another case (using SelBlocks Global). That would be confusing if those cases were associated with different configurations.
A manifest affects to any suite under its folder subtree, unless overridden by manifest(s) at a more specific (lower) level or by a set (at any level). Teams can share common values via values manifest(s), yet team members can override them in their own set(s).
The actual location of case(s) doesn’t matter. They can even be outside of the suite folder. You could run same case(s) through different suite(s), each with different combination of manifest(s) and set(s).
A manifest applies to any suite(s) in its folder or anywhere under its folder (to any depth).
Manifests work only if the module associates with folders. Otherwise the script uses the default set (if the module allows sets) or the only existing set (if the module doesn’t allow multiple sets), or a set with a given name (if requested by an explicit API call). See SettingsAPI.
Value(s) of a multi-valued field come from a maximum of one source (set or manifest) - the topmost applicable from the list above. Multi-valued fields don’t have the values merged from various sets neither from manifests. It would make them more flexible, but also more confusing and fragile. This also applies to FixedMap fields (see SettingsFields).
The rules of applying values from manifests and configuration sets are, in order of priority:
Therefore, a field will have value(s) based on its first occurrence in the following order:
Manifests are cached
SeLiteData.getStorageFromSettings). You need to restart Firefox in order for a change to apply.Symlinks are another way to have variety/separation of configuration sets. If you access a suite via a file path which has symlinked non-leaf folder(s), it can be associated to partially/fully different configuration sets.