Voting starts in March for the Drupal Association Board election.
Configuration schema and data are both versionless. There is nothing to tell if a given yml file is for a given version of a module. Modules however will likely change their configuration structure, such as contrib views plugins would change how they store settings or panels could change how it stores a panel config entity in any release.
The stance so far of the config system on this is "it is up to the module to update the data proper". As with update functions for other things, when you update a module, the update functions would need to take care of updating the config structure from old to new. That in itself is fine.
With the configuration override and schema system however, configuration overrides from the core locale module, from the contrib config_translation module, from the contrib organic groups, from the contrib domain module, etc. might also exist on the system. These contain overrides in the structure of the original config, so when merged they serve as configuration applicable to specific use cases (for languages, domains, groups, etc).
1. When such an update happens, all the modules dealing with configuration overrides need to react to the schema change too. They need to update the structure of the override files, so that they properly map to the new structure. If an override file in an old structure if applied to the new structure, it could lead to negative consequences of different proportions. Therefore when such updates are done, said core and contrib modules would need to have access to the old data and the old schema and the new schema and new data so they can regenerate the overrides in the proper new structure at least to their best effort.
2. Another related problem is how localize.drupal.org works to parse translatable strings from data yml files. When a project is encountered, the parser can look for all the required modules to load their schemas, so any data that is based on required modules can be inspected. Such as a "feature module" that is a couple views and panels and depends on views and panels would need the base schema of views and panels so we can parse their data. Most .info files would not specify concrete version numbers for dependencies (for obvious and good reasons), so localize.drupal.org needs to guess most of the time for the schema version to use. If the module required for the given project has multiple schema variations through its life, the backend will need to pick a version.