What is the problem this feature will solve?

From the docs:

Node.js APIs accept plain Uint8Arrays wherever Buffers are supported as well.

One notable place where plain Uint8Arrays are not always accepted is the methods on the Buffer subclass. Take the method buf.readIntLE(offset, byteLength):

Buffer.prototype.readIntLE.call(Uint8Array.of(1, 0, 0, 0, 0), 0, 3);
// 1

Buffer.prototype.readIntLE.call(Uint8Array.of(1, 0, 0, 0, 0), 0, 4) 
// Uncaught TypeError: this.readInt32LE is not a function
//    at Uint8Array.readIntLE (node:internal/buffer:349:17)

Depending on the byteLength given, the method will respond correctly or throw a TypeError if it happens to be written using a code path that uses an internal method found only on the Buffer prototype.

As a library author, I would also like to easily accept Uint8Arrays wherever Buffers are accepted and not spend time converting the input to a Buffer instance to get useful byte utilities to work on both possible inputs.

What is the feature you are proposing to solve the problem?

I propose to make the few code paths that rely on internal methods invoke those functions in a way that doesn't require them to be defined on the currently bound this value's prototype.

For example:

return this.readInt32LE(offset);

becomes

return FunctionPrototypeCall(readInt32LE, this, offset);

And add coverage for existing and future methods to maintain this contract.

What alternatives have you considered?

A couple but less desirable alternatives:

• Convert input by invoking Buffer.from(ArrayBuffer, byteOffset, byteLength)
• Reimplement the methods in library to work with either input