Your understanding of the specification is indeed correct. These libraries do not follow the transmission protocol required for "FNC1 in first position", i.e. GS1 mode.
The barcode symbology standards are prescriptive: The transmission of the modified AIM symbology identifier is a mandatory part of the generic ISO symbology standards, not only the GS1 application standard.
These individual standards make no attempt to describe the overall framework within which the transmission protocol operates, leaving the reader to guess at the reasons for certain decisions based on an incomplete picture. Also, for historical reasons, these standards presuppose a hypothetical situation in which a barcode reader is connected to a host over a physical, byte-mode interface.
Handheld scanners can normally be configured to emit AIM symbology identifiers (or some proprietary equivalent) as a prefix to the transmitted message and in general will strictly adhere to the prescribed transmission protocol.
However, the typical decoder developer is nowadays writing a library for a device that both hosts the end user application and includes an integrated camera, so the "wire" over which the transmission protocol is performed is nonexistent. It is understandable that developers omit essential features of the standards for which the intent isn't clear, but in so doing they create ambiguities when decoding certain types of data.
Some types of data, such a GS1 Application Identifier syntax, require an explicit activation flag that is canonically signalled by way of a modification to the AIM symbology identier. Rarely does the API of decoder libraries supply a complete replacement for the features indicated by the symbology identifier beyond identifying the generic format of the scanned barcode. For example, device APIs typically lack signalling for GS1 mode and for the ECI protocol extension.
A related issue is that decoder libraries frequently omit to send FNC1 characters in the third and subsequent character position of a barcode message as GS (ASCII value 29), making decoding of GS1 AI syntax messages impossible. Even fewer libraries transmit "%" characters in QR Code symbols in which GS1 mode is activated as GS. These implementations are simply not complaint with the symbology standards.
The maintainer of the port of ZXing to C++ (zxing-cpp) is actively working with the barcode standard setting community to ensure proper compliance with the symbology standards. So ZXing (Java) and the wrappers and bindings ecosystem should benefit from these improvement in due course.