WinDBG - Mismatching JavaScript and dx behaviour

I am writing a simple JavaScript WinDBG script, however, I can't properly map the operands used in an instruction mapped by host.namespace.Debugger.Utility.Code.CreateDissassembler().DisassembleBlocks(addr)[addr].Instructions[addr]

I can list the operands with a for(var o of instruction.Operands) loop, but that doesn't particularly make sense considering that the order of operands is essential.
So I have to convert that manually to an array, hoping that the order is preserved…?

What is even more confusing is that if I evaluate the same expression with dx, it behaves as an array. Namely, dx Debugger.Utility.Code.CreateDisassembler().DisassembleBlocks(0x7900ffff)[0x7900ffff].Instructions[0x7900ffff].Operands[0] does return the first operand, and (…).Operands[1] returns the second operand; while in JavaScript this same exact command will return undefined.

All I was able to find from the documentation is that Operands returns "A collection of operand objects describing the operands of the instruction."

Is this the expected behaviour, or am I missing something?

Edit: As pointed out, a minimal reproducible example:

// Retrieves operand for current instruction pointed by EIP
function run() {
    var p = host.currentThread.Registers.User.eip;
    var instr = host.namespace.Debugger.Utility.Code.CreateDisassembler().DisassembleBlocks(p)[p].Instructions[p];
    host.diagnostics.debugLog(`Operand: ${instr.Operands[0]}\n`); // "Operand: undefined"
    // Incompatible with: `dx Debugger.Utility.Code.CreateDisassembler().DisassembleBlocks(@eip)[@eip].Instructions[@eip].Operands[0]` --> Attributes | ImmediateValue: (…) | Registers
}

The Operands object on an instruction is, unfortunately, just an iterable container. It does not presently support indexing. There is, however, a guarantee that a for...of will maintain the order of what's in the container and that the order of operands in the container is the order of operands within the instruction.

The evaluator for dx has a bit of "extra support" for [] on iterable containers in order to make the debugger hyperlinks function. For any object which is iterable but not indexable, doing [n] within the dx evaluator will, in effect, start iterating the container, advance to the n-th element, and return that. The scripting model does not do that for indexing operations.

That said -- operands is one of those things which should be indexable. I can make sure that gets fixed...