> I'd like to point out that it is also documented completely wrong up to this point in time and thus people who chose True are most likely to be unaware of the actual consequences. A user's explicit choice based on misinformation is not really demonstrating intent to shoot oneself in the foot.

That's why I'm in favor of making the internal change from `SO_REUSEADDR` to `SO_REUSEPORT` (as Nathaniel suggested) and raising a warning for an explicit `reuse_address=True` (as Antoine suggested). If someone has a genuine need for using SO_REUSEADDR, they can do so manually.

This will patch the issue without any maintenance cost to users that didn't explicitly pass `reuse_address=True`, and raise a warning if they did pass it. The majority of users seem to have done did the former, which would make sense. Compare the following GitHub code search results:

All usage of `loop.create_datagram_endpoint`: https://github.com/search?q=%22loop.create_datagram_endpoint%22&type=Code (~3,500 Python results)

Usage of `loop.create_datagram_endpoint` + `reuse_address=True`: https://github.com/search?q=%22loop.create_datagram_endpoint%22+%22reuse_address%3DTrue%22&type=Code (~650 Python results)

Note: the second set of results contains some false positives due to usage of `reuse_address=True` for something else in the same code file. So, the actual number is likely less.

> I'm still attached to the idea that in 3.10 reuse_address and reuse_port are both removed

IIUC, there's only a security concern with the usage of `SO_REUSEADDR`, not `SO_REUSEPORT`. So there's no need at all to remove or deprecate the `reuse_port` parameter. 

> (Provisionally marking this as a security-related deferred blocker issue for backporting)

Thanks, Ned.