Problem/Motivation
If code relies on a core jQuery.once call, with the move to @drupal/once that code might execute more than necessary
Steps to reproduce
This can happens is a piece of code in contrib relies on a call to once from core (or another module that switched to @drupal/once)
// Before
$(el).once('test')// => 1 element
$(el).once('test')// => 0 element
// Problem
$(el).once('test1')// => 1 element
once('test1', el)// => 1 element => KO
once('test2', el)// => 1 element
$(el).once('test2')// => 1 element => KO
// Expected
$(el).once('test1')// => 1 element
once('test1', el)// => 0 element
// OR/AND
once('test2', el)// => 1 element
$(el).once('test2')// => 0 element
Proposed resolution
Support ONLY
On pages where jQuery.once is loaded, calls to @drupal.once will also update the jQuery.once registry.
This covers the use case of core updating to using @drupal/once, but a module is still using jQuery.once and has expectations regarding the contents of the jQuery.once registry.
once('test2', el)// => 1 element
$(el).once('test2')// => 0 element
Calls to jQuery.once will not update the @drupal/once registry
This would effectively be providing two-way compatibility instead of backwards compatibility. A module using @drupal.once should not have functionality that depends on jQuery.once usages or its registry. jQuery.once and @drupal.once can still be used simultaneously - but @drupal.once will intentionally not take jQuery.once's registry into account when determining if something has been "onced". After updating code to use @drupal.once, it should be confirmed any reliance on other module's use of "once" are ones also using @drupal.once.
$(el).once('test1')// => 1 element
once('test1', el)// => 0 element
In this case work with upstream to make them use @drupal/once or stick with using jQuery.once() until it is updated.