Looking for opinions here: would it make sense to be able to tell the block editor plugin not to register its own patterns or update core patterns?

Let's just say we want to be able offer our own library of patterns, or only those available in a WordPress install.

Other than keeping track of every block name that Gutenberg registers, and then manually unregistering them, how could we disable them?

I see two options (assuming the idea itself is sound):

1. Add an apply_filters( 'register_gutenberg_patterns', true ) and apply_filters( 'update_core_patternscheck', true ) for example
2. Standardize patterns names registered by the plugin so we can filter them out more reliably: currently we're registering query/* and social-links/shared-background-color.

I think it's especially important given the comment in the file:

 * Deactivate the legacy patterns bundled with WordPress, and add new block patterns for testing.

For experimental patterns, I think we should be able to opt-out.

Hi @ramonjd! Given this issue is more focused on the pattern insertion experience within post and template editors, I think it would be more effective to create its own issue to discuss this more in detail, as suggested in the related PR. In any case, I think your proposal makes sense, but I would love to hear @ntsekouras' opinion as well.

Thanks for the quick feedback @priethor! I'll do as you suggest, and create a new issue to direct discussion there. Sorry for hijacking this issue!