It shoud be possible to define configuration parameters for a group of wikis – let’s call such a group of wikis a “tag" similarly to MediaWiki’s SiteConfiguration wording. This is already half-implemented, but I’m not sure how to exactly design these tags: their exact capabilities and in what configuration files define them.

In my mind, this could be something like the following schema.

1. a tag is defined in a file (YAML/JSON/PHP array),
2. such a file can contain either a single tag or multiple tags,
3. a tag has a name (which should not conflict with other identifiers) and a list of wikis, suffixes (entire families of wikis), or other tags
4. the list of tags definitions is defined in farms.yml with either a file name or a list of file names

farms.yml:

myfarm:
    server: '(?P<wiki>wiki[0-9]+)\.(?P<family>family[0-9]+)\.com'
    variables:
        - variable: 'wiki'
        - variable: 'family'
    suffix: '$family'
    wikiID: '$wiki$familymyfarm'
    tags:
        - 'tags.yml'
        - '$family.yml'
        - 'tags/*.yml'
    ...

tags.yml and family1.yml:

- name: 'visualeditor'
  wikis:
      - 'wiki1family1'
      - 'family2'
- name: 'default-visualeditor'
  wikis:
      - 'wiki1family2'

(with the possibility if there is only a single tag in the file to omit the initial dash)

tags/parserfunctions.yml:

- wiki2family1
- wiki3family1
- family2

(in this case the file name is the tag name.)

Other questions to come in my mind:

1. Should we think, now or later, about an implicit tag hierarchy, e.g. a tag which the name suffix is another tag name is a subset of the other tag? e.g. 'default-visualeditor' is included in 'visualeditor', so if the later tag activates the VisualEditor extension (as the name suggests it) and the former enables by default the VisualEditor but don’t explictely activates the VisualEditor extension (as the name suggests it), wikis with the former tag would have implicitely the VisualEditor extension activated; an advantage is you have shorter configurations; a drawback is you should always take into account this fact when you define your tag names
2. as a general side question (not to be answered here), should namespaces be defined in the configuration? I mean define a configuration parameter (e.g. wgUseTidy) for 'tag:tidy' ('tidy' is the tag name) and this would be different from a wiki named 'tidy' (e.g. with a long explicite name 'wiki:tidy') or a suffix (e.g. 'suffix:tidy'). This would help to avoid naming conflicts, but it would make the whole configuration a bit longer and possibly harder to read (or not).
3. As presented above, a tag is an “OR” list: every wiki in the list is in the tag (“union” tag); should it be defined “AND” lists: a wiki is in the tag only if it belongs to all list items (“intersection” tag). In this case, obviously the list items should be suffixes or tags. An exemple use case would be a tag activating the VisualEditor extension, another tag activating the BetaFeatures extension, and a third tag defining the VisualEditor as a default Beta Feature (possibly not a very good example, but it gives the idea).