Try deleting and re-adding the integration?, else it’s probably a bug.
FYI. I tend to stay away from updates unless absolutely necessary, or a feature I need has been added, or after the bugs have been worked out, usually around release 2022.4.3+
Best case: it needs just needs documenting and someone will explain how you can do it and close the issue.
Worst case: it needs reverting to recover the functionality in which case the issue will be closed and you will be told to open a feature request here on the forum.
The media_player.select_source service call will continue to accept favorite names. This compatibility feature may be removed in a future release, but there are no current plans to do so.
For now a workaround could be in creating a select list that contains the favorites and then do a media_player.select_source on select. It does however result in a double administration, which is not at all ideal.
The source_list attribute used to be stored in the state machine (like any entity’s state and its attributes). As of 2022.4.0, the attribute was eliminated and source_list is now stored in the hidden .storage/core.entity_registry file as part of a (Sonos) media_player’s capabilities.
I don’t know of any template function able to get an entity’s data stored in core.entity_registry.
In contrast, for a device, the device_attr function allows you to get data from the core.device_registry file.
If there was an equivalent entity_attr function, then one could get an entity’s data, like capabilities and platform, stored in core.entity_registry. Perhaps this merits a Feature Request.
EDIT
I was wrong. The author of the Sonos integration (jjlawren) explained the source_list in storage/core.entity_registry is created at the moment the Sonos media_player entity is created and then never updated again. There’s no point in attempting to access it because it’s a static list.