To further elaborate on why those instructions were unusable, the sorting in the LAX array happened to do its compares in such a way that it at first did the ZP,Y comparison of the ",Y" trail before doing the (IND),Y comparison of the "),Y" trail, so it was always falsely interpreted as a ZP,Y instruction due to comparison order. I now re-ordered all the unofficial instruction arrays in the same manner as official instructions to fix that issue.
For the ISC instructions, the compiler by default considers all opcodes in an opcode array as processed if it found -1 (0xFF) as opcode, which just so happened to be the value of "ISC ABS,X", meaning both the ABS,X and ABS,Y comparisons in the ISC array never happened and it would always call those 2 invalid instructions.
To fix this issue, I now check against the opcode type instead by adding a -1 behind each opcode array and changing the compare from the opcode itself (op[0]) to the type instead (op[1]) at line 2429.
To further elaborate on why those instructions were unusable, the sorting in the LAX array happened to do its compares in such a way that it at first did the ZP,Y comparison of the ",Y" trail before doing the (IND),Y comparison of the "),Y" trail, so it was always falsely interpreted as a ZP,Y instruction due to comparison order. I now re-ordered all the unofficial instruction arrays in the same manner as official instructions to fix that issue. For the ISC instructions, the compiler by default considers all opcodes in an opcode array as processed if it found -1 (0xFF) as opcode, which just so happened to be the value of "ISC ABS,X", meaning both the ABS,X and ABS,Y comparisons in the ISC array never happened and it would always call those 2 invalid instructions. To fix this issue, I now check against the opcode type instead by adding a -1 behind each opcode array and changing the compare from the opcode itself (op[0]) to the type instead (op[1]) at line 2429.