The QR Code 2005 specification states that ISO 8859-1 is the default interpretation for data encoded using byte mode. However, QR Code 2000 instead specified the Shift JIS character set, which has created some understandable historical confusion. FileMaker Go's Insert from Device script step may interpret QR Code data encoded using byte mode as being from either of these character sets, depending on the data. (FileMaker Go seems to prefer interpreting all the data as Shift JIS whenever possible, but interprets the data as ISO 8859-1 when the data obviously do not make sense as Shift JIS.) This behavior seems to be a well intentioned attempt to accommodate QR Codes encoded expecting both interpretations, but I have found that it creates as much confusion as it resolves.
I suggest that FileMaker Go would be better off if it stuck to exclusively interpreting QR Code byte mode data using ISO 8859-1 (Unless a different ECI is indicated by the QR Code).
To be fair, QR Code 2005 does allow a different choice of default character set for byte mode:
"In closed-system national or application-specific implementations of QR Code 2005, an alternative 8-bit character set, for example as defined in an appropriate part of ISO/IEC 8859, may be specified for Byte mode. When an alternative character set is specified, however, the parties intending to read the QR Code 2005 symbols require to be notified of the applicable character set in the application specification or by bilateral agreement."
If FileMaker Go continues to use it's current decoding method, I would at least appreciate documentation of how FileMaker Go deviates from the default. (The current behavior is not the default specified for either QR Code 2000 or QR Code 2005.)