As for kernel interrogation, it certainly is possible on early boot to get the kernel capabilities we are interested in and put them in a file or hash for quick checks (along the lines of @mvo’s digest idea), but like you said, we need to now manage this file which adds complexity. Perhaps populating this file via a systemd one-shot early boot unit would make this robust-- but we’d have to consider cross-distro packaging to put that one-shot unit in place.
apparmor_parser --version, I just remembered that /snap/core/current/usr/share/snappy/security-policy-version exists for similar reasons and it contains (along with some ubuntu-core-security-* cruft that should be removed) the apparmor version installed in the core snap. We’d have to read/parse that file but that is faster than an exec of apparmor_parser (@mvo’s digest could make that faster, but see above). Changes to this file don’t necessarily indicate syntax changes though-- indeed, it has the Ubuntu version and it will rev with SRUs, but there aren’t that many SRUs, so it may not be a problem.
Alternatively, if we decided the one-shot systemd early boot unit idea was the way forward, we could instead of looking at /snap/core/current/usr/share/snappy/security-policy-version run
apparmor_parser --version as part of that one-shot.