The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: sirreal <jonsurrell@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Flaky tests detected in 8de8923.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17974568163
📝 Reported issues:

• [Flaky Test] ensures List View global shortcut works properly #51533 in /test/e2e/specs/editor/various/list-view.spec.js
• [Flaky Test] should select the wrapper div for a group #71211 in /test/e2e/specs/editor/various/block-hierarchy-navigation.spec.js
• [Flaky Test] should show correct homepage actions based on current homepage or posts page #68892 in /test/e2e/specs/site-editor/homepage-settings.spec.js

Thanks for the PR!

Disallow extra properties in the supports.colors block.json schema.

I'm not sure if we should do this or not - block.json is just a JSON file, and consumers may have extended the core support or added their own.

{
	"$schema": "https://schemas.wp.org/trunk/block.json",
	"apiVersion": 3,
	"name": "myplugin/myblock",
	"title": "My Block",
	"supports": {
		"color": {
			"text": true,
			"myPlugin": {
				"myPluginColorControl": true
			}
		},
		"myPlugin": {
			"myPluginCustomControl": true
	}
}

In this PR, how about just updating the API version and doing the schema-based check in #71851?

There is also a discussion on how to add custom support: #71012

I removed the other changes and just updated the apiVersion in the schemas.

I'm not sure if we should do this or not - block.json is just a JSON file, and consumers may have extended the core support or added their own.

There is also a discussion on how to add custom support: #71012

Allowing arbitrary extra properties weakens the schema. It would be nice if they were at least required to follow a prefix like customMyProperty. Then we could allow them without weakening the schema by allowing arbitrary keys which is why issues like #71800 happen.