Let's use the jQuery style guide in code samples which means double quites:

You've actually already used double quotes on a similar example below.

...except for some JSONP scripts. But maybe conceptually JSONP is separate from script even though it's using the same infra underneath? What do you think? Is it worth mentioning it here or would it just be confusing?

Code style + we've used uppercase types so far in similar texts:

Let's document them all - although I'm fine with doing it in a separate PR. You can always start with relevant entries from https://github.com/jquery/jquery-migrate/blob/main/warnings.md.

Also, with so many entries, maybe it'd be better to dedicate a small section to each of them, with a separate header as in the toggleClass case above.

This is no the only case of a breaking change; I'd even argue it's a less common one. Even more so, now keys matching Object.prototype keys should just work so it's hard for me to imagine what could break in this case.

The case that breaks is if someone used .data() to get the whole data object and then e.g. called hasOwnProperty on it.

Not of jQuery(); of jQuery.fn.init(). jQuery is already skipping this argument even on 3.x-stable (https://github.com/jquery/jquery/blob/3.x-stable/src/core.js#L33-L38):

	jQuery = function( selector, context ) {

		// The jQuery object is actually just the init constructor 'enhanced'
		// Need init if jQuery is called (just allow error to be thrown if not included)
		return new jQuery.fn.init( selector, context );
	};

while in jQuery.fn.init it exists there (https://github.com/jquery/jquery/blob/3.x-stable/src/core/init.js):

	init = jQuery.fn.init = function( selector, context, root ) {

Let's also mentioned this is the third parameter.

From my summary:

* CSS: Remove the opacity CSS hook
    * 865469f5e60f55feb28469bb0a7526dd22f04b4e
    * The consequence is `.css( "opacity" )` will now return an empty string for detached elements in standard-compliant browsers and "1" in IE & the legacy Edge. That behavior is shared by most other CSS properties which we're not normalizing either.

Let's mention that now .css( "opacity" ) on disconnected elements will return an empty string instead of "1" in modern browsers. I expect some code may depend on the "1" default.

I'd mention that the .data() setter used to convert -ms-x to msX and now to MsX. This is a result of separating camelCase logic between data & css modules.

Some people used our AMD modules directly; I'd mention that jQuery source is now authored using ESM and code under src/ is in ESM.

What's cool is that it works natively in the browser as well. You can just do - assuming you have jQuery cloned into the folder jquery next to the HTML file, or downloaded from npm:

<script type="module">
	import { $ } from "./node_modules/jquery/src/jquery.js";
	/* ... */
</script>

or, using import maps:

<script type="importmap">
{
	"imports": {
		"jquery": "./jquery/src/jquery.js"
	}
}
</script>
<script type="module">
	import { $ } from jquery";
	/* ... */
</script>

and it works without any build process while importing all the individual jQuery modules natively. Of course, you can also import our built module file:

<script type="importmap">
{
	"imports": {
		"jquery": "./node_modules/jquery/dist-module/jquery.module.js"
	}
}
</script>
<script type="module">
	import { $ } from jquery";
	/* ... */
</script>

It's pretty cool that it works, I'd mention it with some examples.

Should we mention Ajax now supports binary data in bodies - the minor breaking change is that prefilters are now fired a bit earlier, before converting the body to a string? This is a pretty important feature.

I know some of that may only make sense in the blog post. But there's a small breaking change attached here.