What is the issue with the Web IDL Standard?

Opening an issue per the wording here: https://webidl.spec.whatwg.org/#limit-bigint-numeric-unions

It would not be appropriate to accept such a union, only to then convert values of the numeric type to a bigint for further processing, as this runs the risk of introducing precision errors. Please file an issue before using this feature.

We have 3 use cases in WebNN where we need to be able to accept full precision from the API and retain it passed all the way down to the bottom, because float64 cannot express the full precision of int64 (and conversely, an int64 could not express the full precision of a float64).

• adding padding (Type of some parameters should match the input data type webmachinelearning/webnn#442)
• clamping a range (Type of some parameters should match the input data type webmachinelearning/webnn#442)
• filling in a tensor with sequential values (Constant sequential filling operation needs output shape parameter webmachinelearning/webnn#492)

Evidently it's murky territory, as Bin Miao hit a bug in the Chromium implementation "We met the problem of using the keyword or in IDL to create a union type containing double and bigint. In the generated file 'v8_union_bigint_double.cc', it was only judged that the incoming data was of JS number type and there is no judgment that it is BigInt, which causes an error to be reported when BigInt data is passed in when calling this API using JS code.", and Joshua notes that "Use of bigint is extremely limited in Chromium at the moment, so I'm not surprised if the binding code generation can't handle a union with it yet ... this may just be the first spec".

FYI @inexorabletash, @annevk, @Honry, @miaobin