data/platforms.yml uses x86 as the preferred spelling for the shared ABI of all 32-bit x86 CPUs, and i386 as a compatibility alias.

This makes Appstream almost, but not quite, compatible with the multiarch tuples used in Debian, the freedesktop.org SDK and systemd, which seems unfortunate.

The "big idea" of the Debian multiarch tuples was that they are GNU Autotools tuples, with two changes that were necessary in order to flatten all cross-compatible tuples into a single tuple per ABI:

• the vendor part of cpu-vendor-kernel[-abi] is omitted, similar to cross-compiler tool prefixes, so it's x86_64-linux-gnu rather than x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu;
• the cpu part is defined to be normalized to the oldest or most generic CPU in a family of compatible ABIs, so it's i386-linux-gnu or arm-linux-gnueabi, not i686-linux-gnu or armv5tel-linux-gnueabi (in practice the only architectures affected by this seem to be the 32-bit x86 and ARM families).

If Appstream treated x86-linux-gnu as a compatibility alias for i386-linux-gnu instead of the other way round, then I think its tuples would exactly match multiarch tuples, with the possible exception of x32 (which has GNU and multiarch tuples x86_64-linux-gnux32, whereas Appstream currently only recognises the gnu_ilp32 used for the equivalent ILP32 ABI on ARM - but x32 is basically dead so this maybe isn't a big problem).