At the top of .remove() it says:

In addition to the elements themselves, all bound events and jQuery data associated with the elements are removed. To remove the elements without removing data and events, use .detach() instead.

So I think that case is covered.

I think I know the cases you're talking about, where people somehow expect that once they wave their $("div").on("click"...) magic wand that all divs ever put onto the page have a click handler. There's a whole section on .on() already that tries to explain how you can use delegated events to deal with that.

Ideally any clarification would not involve adding a lot more words to that page since it is already a very long read. Are there some specific changes you can think of that would help?

Yeah, you're on the right track - more specifically it's cases where they think that simply using a delegated listener is enough - e.g.:

$('.someDiv').on('click', '.someChild', function() {
    $('.someDiv').remove();
});

They then later re-add $('.someDiv') and expect it to work because it's technically bound to an element that exists at the time of binding

I wholly agree that the docs for .on() are very wordy, which is partially why I think people don't fully grok this concept - it can be a lot to take in. For this case, I was considering something very simple, like changing this text:

Event handlers are bound only to the currently selected elements; they must exist at the time your code makes the call to .on().

To something like this:

Event handlers are only bound to elements that exist at the time your code makes the call to .on(); elements that are deleted and later recreated are considered new and, therefore, aren't covered.

I'm having a hard time coming up with a good way to phrase this, so any suggestions would be welcome. Maybe a review/light rewrite of these docs would be useful? Any thoughts would be appreciated.

Maybe we could cover this on learn.jquery.com instead, and point people to it on event-related pages? In fact there is probably a bit of stuff already there that could be moved to learn. The page could reference more detailed discussions in several places if needed. Like I said, I'm concerned that page is getting too long to read, which means no matter what we say there it won't be read.

I'm +1 for adding a note about it to the learn site. @robertmaxrees Would you mind opening an issue in there?

Issue created for the learning center.

Do we want to spin up another issue to address desired changes to the docs for .on()?

I'd wait on that until it's clear what we're doing to the .on() API page, which is dependent on the path of the learning changes.