When dynamic type definitions are involved in configuration schemas, it was not possible to match the type with plugin derivatives, which use ':' as a separator for plugin identification to separate the derivative identifier and the base identifier. Consider this schema from block module:
block.block.*:
type: config_entity
label: 'Block'
mapping:
#...
settings:
type: block.settings.[%parent.plugin]
In this case, the type of the settings key is determined based on the plugin identifier in the parent. Consider this actual configuration:
#...
id: bartik_footer
plugin: 'system_menu_block:footer'
settings:
visibility: { }
#...
The type for the settings value in this case is block.settings.system_menu_block:footer. Schema may be provided for this specific type. However, the schema system did not provide a way to specify schemas in general for system menu block derivatives (regardless of their menu ID), that is for block.settings.system_menu_block:*. That is because asterisks in configuration schema only matched from a dot to another dot or the end of the name, it was not possible to use an asterisk with/after a colon.
We now made it possible to use this configuration, so plugin derivatives can provide schemas based on the main part of the plugin identifier now. It is now possible to define configuration schema for system menu blocks then as:
block.settings.system_menu_block:*:
type: mapping
mapping:
#... the rest of the definition.
