Ability to display block_content entities independently, also outside of Blocks

Wonder if anyone can confirm if ✨ Add view tab + standard template for block content Needs work solves the problem?

Thanks @smustgrave, it'd be great to move this forwards! However there were (at least) a couple of reservations raised with the general idea IIUC:

block_content entities simply aren't designed to be displayed in another way, if you check the view builder you can also see that it explicitly works around render caching and has that disabled.

So the answer to this might simply be that this is on purpose, if you want to display something with views or references or ..., then don't use block_content but either a node type or custom entity type. I understand that not everybody will like that but I'm not sure I see an alternative for keeping it working correctly and efficiently (=no double-render caching of the same content, for example) also within a block.

https://www.drupal.org/project/drupal/issues/2704331#comment-11863202 ✨ Ability to display block_content entities independently, also outside of Blocks Postponed: needs info

block_content entities are exposed as block plugins and saving reusable blocks triggers a block plugin discovery. The more of them you have the more expensive that becomes.

https://www.drupal.org/project/drupal/issues/2704331#comment-14604615 ✨ Ability to display block_content entities independently, also outside of Blocks Postponed: needs info

I don't really grok the double render-caching issue and it's not clear to me why using a custom entity type might be better

If I build a custom entity type that's similar to block content entities and is for embedded content... I can see at some point being asked to write a plugin to make it accessible to the block system so that we can place these embeddable entities that way too. And then aren't we back in the same situation?

https://www.drupal.org/project/drupal/issues/2704331#comment-13474270 ✨ Ability to display block_content entities independently, also outside of Blocks Postponed: needs info

Some things to consider.
The real challenge seems to be determining if block_content entities need to remain coupled with block plugins.

Based on the information shared:

1. Caching is tightly coupled between block_content and block plugins
2. Block plugin discovery is tied to block_content creation
3. Block plugins are not configurable to conditionally attach entities. There is a unique relationship with block_content and block plugins.

In response to the caching issue, do we already have an example of double-render caching for the same content in Drupal core? If so then I think the argument is invalid.

In response to the block plugin challenges, I see this as an opportunity to make the block system more configurable and dynamic for scalability and flexibility. If we make a block plugin that can conditionally attach a block_content entity (or others for that matter) then I see that increases its usefulness and meets the existing expectation. This removes the need for block discovery to be triggered on block_content creation.

This not only impacts views and references but also impacts using twig_tweak to print a block_content entity in a template. I see all of these as valid use cases and I think the increasing usage of the block_content_template module shows that it should be evaluated.