Should `transferToImmutable` support a `newByteLength` argument?

[erights]

In favor: Least surprise. Minimize consequences of reasonable surprise. If we add this parameter, those who expect it not to be there and don't provide such an argument get what they expect anyway. OTOH, if we omit it, those who expect it to be there and provide such an argument do not get either a static or dynamic diagnostic. Rather, the code proceeds to silently do something other than they expect.

Against: It might be useful for truncation, but probably rarely for expansion because the output would have an all-zeroes suffix that could not be changed.

Both sides can also make arguments from orthogonality:

• In favor is more orthogonal because the parameter exists and means the same thing across all transfer* operations.
• Against is more orthogonal because making a buffer immutable is distinct from changing its size, and can be painlessly composed with a transfer operation which does change the size, while still being zero-copy.

[erights]

I find the "Minimize consequences of reasonable surprise" argument the most compelling, so I'm inclined towards including this parameter. This would involve a change to the spec and shim as currently (1 dec 2024) written. The Moddable XS implementation already implements this parameter, and so would not need to change.

If tc39 agrees, I'll close with this decision.