it looks like the validation order of receiver.set(source, offset) is basically

1. Throw if receiver is not a TypedArray.
2. [in ToIntegerOrInfinity] Throw if offset fails to coerce to a Number.
3. Throw if offset coerces to negative.
4. [later steps are in SetTypedArrayFrom{TypedArray,ArrayLike}]
5. Throw if receiver is associated with a detached ArrayBuffer.
6. [only in SetTypedArrayFromTypedArray] Throw if source is associated with a detached ArrayBuffer.
7. [only in SetTypedArrayFromArrayLike] Throw if source fails to coerce to an Object or fails to return a "length" that coerces to a Number (which is otherwise clamped to the inclusive interval from 0 to 2**53-1) for later steps).
8. Throw if offset is infinite or offset plus the length of source exceeds the length of receiver.
9. [only in SetTypedArrayFromTypedArray] Throw if receiver and source have different [[ContentType]] (one BigInt while the other is Number).

It makes sense to reject infinite offset at the same place as rejecting finite-but-too-big offset (since both are effectively the same issue), but the overall behavior would be better if it were consistent with how-we-work#119 and performed all validation of offset in the same place after getting the length of source—i.e., moving steps 2 and 3 above to immediately before step 8 (and ideally also moving step 9 above to immediately after step 6). Such error reshuffling would indeed be normative, but probably safe (if perhaps too minor to be worthwhile).

for // 6. Let rawValue be a List of elementSize containing, in order, the elementSize sequence of bytes starting with block[byteIndex]., i was doing var rawValue = $slice(new $Uint8Array(arrayBuffer), byteIndex, 0, elementSize); // step 6

and i changed it to var rawValue = $slice(new $Uint8Array(arrayBuffer, byteIndex), 0, elementSize); // step 6