Description
I believe the motiation of this proposal could and should be addressed by a pure ECMA262 solution. Consider the following changes to ECMA262
Change
21.4.4.41 Date.prototype.toString ( )
https://tc39.es/ecma262/#sec-date.prototype.tostring
21.1.3.6 Number.prototype.toString ( [ radix ] )
https://tc39.es/ecma262/#sec-number.prototype.tostring
21.2.3.3 BigInt.prototype.toString ( [ radix ] )
https://tc39.es/ecma262/#sec-bigint.prototype.tostring
to
21.4.4.41 Date.prototype.toString ( [options] )
21.1.3.6 Number.prototype.toString ( [ radix ] [ , options ] )
21.2.3.3 BigInt.prototype.toString ( [ radix ] [ , options ])
and specify how these three functions should read the options and create the formatted result string differently
The options read and respected by Date.prototype.toString will be only a subset of what the toLocaleString accept
For example, it will NOT read "localeMatcher", "calendar", "numberingSystem", "hour12", "dateStyle", and "timeStyle", but will read "hourCycle", "timeZone". And those list in https://tc39.es/ecma402/#table-datetimeformat-components could be decided by the proposal to include for reading or not.
The options read and respected by Number.prototype.toString and BigInt.prototype.toString will be only a subset of what the toLocaleString accept
For example, it will NOT read "localeMatcher", "numberingSystem", "style", "currency", "currencyDisplay", "currencySign", "unit", "unitDisplay", but will read other options listed in https://tc39.es/ecma402/#table-numberformat-resolvedoptions-properties