ACL !!! FRONTEND !!!

For a given usergroup of article writers: Don’t grant any action rights on articles for this usergroup in System>Config>Articles. Then have a category and grant all action rights to the usergroup there. The writers will then be able, to create and edit articles, that are stored in that category (or a subcategory).
This worked fine in the past. And it works fine currently: BUT: Does no longer work correct for ‘modify state’ action (although the computed inherited rights are shown correct in the category – but system in reality does not behave that way any longer).

Steps to reproduce the issue

Create a new top-level category ‘TestCatego’
Create a new usergroup ‘TestGroup’ as direct subgroup of ‘registerred’
Create a new accesslevel ‘TextAccLevel’ containing just ‘TestGroup’
Register a user ‘TestUser’ an attach it with ‘TestGroup’
Create a menuitem with TestAccLevel showing the articles in TestCatego as a blog

System > Configuration > Articles > Rights:
Ensure that you do not explicitly enable oder disable any rights to TestGroup. This shall lead to ‘disabled (inherited)’ for all article actions for TestGroup.
Content > Categories > Select category ‘TestCatego’ > Rights:
For TestGroup explicitly grant the following rights: create / edit / edit your own / modify status

Expected result

The calculated rights (after saving) will show, that a user of this group will be able to do the granted things in category TestCatego: Especially: Will be able to modify the status of any article in this group.
That is the behavior to be expected.

Actual result

The system does NOT behave in this way: The user will not be able to modify the state of an article in this category IN THE FRONTEND.

The expected behavior might be achieved by a workaround: Explicitly allow ‘modify status’ in ‘System > Configuration > Articles > Rights’ for TestGroup. BUT: From now on any user in TestGroup will be shown any hidden or no longer published article on the website – which is not the expected behavior again.

In my eyes there must be a piece of code, dealing with ‘modify state’ in a wrong way?

System information (as much as possible)

Joomla 3.9.6