note that the second parameter to R and MCR is the basis, and that the code previously used 1 -> PauliX, 2 -> PauliY, 3 -> PauliZ. However, the underlying code in capi.cpp would convert this integer into an enum that was defined as:

enum Basis
{
    PauliI = 0,
    PauliX = 1,
    PauliY = 3,
    PauliZ = 2
};

This change fixes the use of integers for Pauli basis to correctly line up with the definition in capi.cpp.

note that the second parameter to R and MCR is the basis, and that the code previously used 1 -> PauliX, 2 -> PauliY, 3 -> PauliZ. However, the underlying code in capi.cpp would convert this integer into an enum that was defined as:

enum Basis
{
    PauliI = 0,
    PauliX = 1,
    PauliY = 3,
    PauliZ = 2
};

This change fixes the use of integers for Pauli basis to correctly line up with the definition in capi.cpp.

Is there a justification for using one ordering over the other? It makes more sense to me to me, as just a casual observer, that the order should go XYZ not XZY.

𝑋𝑍𝑌 is very common when considering the stabilizer formalism or binary symplectic form, since the Pauli operators are represented by bitstrings as 𝑋 = (1 | 0) = 1, 𝑍 = (0 | 1) = 2, and 𝑌 = (1 | 1) = 3. More generally, in the binary sympelectic representation, each Pauli operator on 𝑛 qubits is represented by 2𝑛 bits, where the first 𝑛 bits index 𝑋 operators and the next 𝑛 bits index 𝑍 operators. The third-party simulator at https://github.com/qsharp-community/chp-sim makes extensive use of this convention, for example.

I should note, btw, that in Q# versions < 0.8, we used the 𝑋𝑌𝑍 ordering; that change was made with #11 (comment).

I had the same question as Scott, and thanks for addressing it, Chris! It certainly seemed like an intentional choice, and it's good know the reason why! Of note, this never cause a problem before because Ry was only used in tests where it was almost immediately uncomputed with negative angles (to perform the adjoint) and until my recent change #338 the CRz function was unused.