Is using derived keys for HKDF + AES-GCM safe
By itself, this is fine. Running a KDF with two different inputs generates uncorrelated sequences: knowing the output of HKDF(K1, L) doesn't give any information about the output of HKDF(K2, L) unless K1 = K2.

However, as a system design, this is fragile. What if one day someone decides that they need a new version of this format, and they decide to flip the last bit of key?

Given the constraint that you can only change the key input to HKDF, if key has a fixed size, I would append a suffix to key to indicate the format version. Version 0 uses an empty suffix, version 1 will use the 4-byte suffix {0x00, 0x00, 0x00, 0x01}, etc.

If there is an additional constraint that key has to remain the same size, I would run it through a KDF first. To avoid running into potential trouble with related keys, key should still only be used for a single purpose, which is as the key input to HKDF. Use a label that cannot possibly be equal to any valid value for info.

key' &lt;- HKDF-Expand(key, "not a possible prefix of info; version 1")
(_, key1) &lt;- HKDF-Expand(key, info)
(_, key2) &lt;- HKDF-Expand(key', info)