[policy, no patch] Updating core JavaScript APIs gracefully.

Problem/Motivation

This is inspired by several current issues:

• 📌 Provide a new library to replace jQuery UI autocomplete Needs work : needed to remove the end-of-life jQueryUI
• 📌 Add a native dialog element to deprecate the jQuery UI dialog Needs work : also needed to remove the end-of-life jQueryUI
• 📌 Remove Tabledrag's jQuery dependency Needs work : a significant step in removing core's overall jQuery dependency.

These issues are implementing large-but-necessary changes to core JavaScript. It is unlikely that any of these can be implemented in a manner that is 100% backwards-compatible or that provides full deprecation notice of changed/removed features, but it's also risky (and probably cruel) to only provide these changes to the Drupal 10 branch.

The issues listed above are likely the first of many, so it would be beneficial to come up with guidelines on how to implement these complex changes that can result in API changes.

Proposed resolution

While there's likely no one-size-fits-all solution for this, we should create a policy that will help us determine how a given change gets implemented.

Some approaches to consider (keeping in mind that no single approach will likely work for every change):

• An optional module for replacing specific functionality, such as what is being done for autocomplete in 📌 Provide a new library to replace jQuery UI autocomplete Needs work , with dedicated modules for each new piece of functionality. Each module would be accompanied by deprecation notices when using the features they replace. Perhaps all of these modules can be categorized by a package name that indicates they are the modern replacements for specific functionality.
• A single module that takes care of all JS replacements. This is similar to the previous option, but would simplify things by making it a single module (which has the drawback of making all replacement options unavailable, even if it's just one that is incompatible with a site)
• Determining what level of BC support should be assured. For example, when replacing jQueryUI widgets, is it necessary to support BC for methods/config not used by core and no eveidence of being used by contrib? For something like Tabledrag, what is a reasonable BC expectation for contrib that extends it?

Things that need to be considered when evaluating an approach:

• The dedicated module approach makes it easy to return to old functionality if compatibility issues arise, but also introduces the possibility of contrib having to support two versions of the same API.
• What is a reasonable level of overhead for shimming features unused by Core and with no evidence of use in contrib. Although 100% BC support is the ideal, and the most virtuous hill to stand on, it can be at the expense of other Drupal advancements and bugfixes, and can introduce maintainability challenges to support functionality that has little to no use.
• How granular should deprecation notices get? Methods with additional/now-unnecessary args, any no-longer-used config property?

There are likely more options and considerations than the above. There's a great deal to think about here. People should feel free to add these additional points to this issue summary.

Remaining tasks

📌 Better define the backwards compatibility/API policy for JavaScript Active
Come up with some guidelines