For !588 (merged), I wanted to guess whether Vulkan drivers are actually amd64-only or i386-only from whether they were found in one of the Flatpak-specific, architecture-specific locations, and if they are architecture-specific, don't make them available for "the other architecture".
However, that doesn't actually work, because the Steam Flatpak app adds its Vulkan extensions to XDG_CONFIG_DIRS, which means they're actually searched by libvulkan of both word sizes. My implementation was clever enough to recognise that anything found in the XDG_CONFIG_DIRS is searched by both loaders, and not mark it as architecture-specific.
This is sort of our fault, because we backport libvulkan in scout, and that copy from scout can be (and in practice sometimes is) newer than the one in the fdo SDK. Because the copy in scout is basically upstream libvulkan, it doesn't know the Flatpak-specific search directories, resulting in it not finding Vulkan layers and drivers from the architecture-specific paths in the extensions. The maintainers of the Steam Flatpak app worked around this by copying those search paths into XDG_CONFIG_DIRS (see https://github.com/flathub/com.valvesoftware.Steam/issues/541). Ideally they would have set up an architecture-specific search path instead, but libvulkan has no such thing, so...
The last commit here is also unfinished: it's not quite right, and I realised it wasn't actually going to be practically useful as a result of the above, so I didn't bother to finish it.
I think this branch is probably a dead end, but I wanted to put it up as a possible source of future inspiration before closing it.
graphics: Track whether files were found in an arch-specific directory
The standard search paths used for EGL and Vulkan JSON manifests are architecture-independent (/etc, /usr/share), but Flatpak runtimes have some non-standard search paths which are architecture-specific. When we find a Vulkan layer in one of those architecture-independent paths, we'll want to record it as potentially architecture-specific.
Note that this doesn't actually work at the time of writing, because the Steam Flatpak app adds its Vulkan extensions to XDG_CONFIG_DIRS, which means they're actually searched by libvulkan of both word sizes. This is because the Steam Runtime's relatively upstream-like libvulkan is (or can be) newer than the fdo SDK's patched libvulkan, resulting in it not finding Vulkan layers and drivers from the architecture-specific paths in the extensions (see https://github.com/flathub/com.valvesoftware.Steam/issues/541). However, it can be tested by setting XDG_CONFIG_DIRS=/etc/xdg explicitly.
graphics: Expose library architecture guessed from location as a property
As with the previous commit, this doesn't actually work in the Steam Flatpak app at the time of writing, but it can be tested by setting XDG_CONFIG_DIRS=/etc/xdg explicitly.
graphics: Add an issue flag for unexpected architectures
If we find a JSON manifest in an x86_64-linux-gnu directory that says
"library_arch": "32", or vice versa, then something is not right.
Skip copying JSON manifests for libraries found in the other architecture's arch-specific location
The beginnings of some work to edit
library_archinto SONAME-based manifests if they were found in the arch-specific location