Capture all reasons why particular SDC is incompatible

I ran across this scenario while exploring the component listing in admin/structure/component

• By default, the experimental component (components/sdc_statuses/experimental) is listed in the component listing and is active.
• Change the status of the component from experimental to obsolete in experimental.component.yml
• The component gets disabled in the component listing (Expected)
• The component gets added in the 'Disabled components' section (admin/structure/component/status) with reason "Component has "obsolete" status" (Expected)
• Changed the status back to experimental in experimental.component.yml
• The component will still be disabled in the component listing
• The component will still be present in the disabled components section with the same reason "Component has "obsolete" status" . Since the component is disabled, it should be listed under the 'Disabled components' section. But the reason is incorrect. I am not sure what reason to use in this case though. Already, there is a 'Manually disabled' reason. But that's also not quiet right for this scenario.

wim leers → credited el7cosmos → .

wim leers → credited longwave → .

Merged 📌 Display disabled Block components in /admin/structure/component/status Active into this, reason:

I'm 95% confident that this is a duplicate of 📌 Capture all reasons why particular SDC is incompatible Active .

Why?

Because for the disabled SDC-sourced Components to be listed at /admin/structure/component/status, XB's decorated SDC plugin manager stores the necessary information in the State service under the \Drupal\experience_builder\Plugin\ComponentPluginManager::REASONS_STATE_KEY key.

To make Block-sourced Components also get listed at /admin/structure/component/status, it'll also need to end up being stored in that same key-value pair.

Conclusion: to make the UI treat both ComponentSources the same, the infrastructure needs to change. Which inevitably requires touching the same code paths.

P.S.: this likely will also require refactoring experience_builder_block_alter() away in favor of XB decorating the Block plugin manager (just like it does for the SDC plugin manager).

— yours truly at #3484672-4: Display disabled Block components in /admin/structure/component/status →

Transferring issue credit.