This shouldn't need special casing. If the LOAD_ATTR_INSTANCE_VALUE get de-optimized, the preceding LOAD_FAST__LOAD_ATTR_INSTANCE_VALUE is still valid, just less likely to hit.
Given how unlikely a branch to the LOAD_ATTR is, don't worry about this case.

Since the combined instruction borrows the cache from the following instruction, I was worried about the combined instruction misinterpreting some of the cache data, so that's why I was attempting to keep them in sync.

But it seems that the instructions in the LOAD_ATTR family all interpret the cache entries in the same way, so for now anyway, if there's ever a correct cache1->tp_version, then cache0->index should be correct: you can't turn something with a class that has a _PyObject_ValuesPointer into a class with __slots__ without modifying tp_version_tag. (right?)

This might not be true though if we ever specialize instance.class_attribute. In that scenario, a LOAD_ATTR_INSTANCE_VALUE cache entry could have a cache1->tp_version and a cache0->index into the values array of the instance, but then later get de-optimized and re-optimized to the hypothetical LOAD_ATTR_CLASS_ATTRIBUTE, which could (?) have the same cache1->tp_version but a cache0->index indexing into types's value array.

It feels less fragile to me to keep the adjacent instructions in sync, so that cache is only interpreted in one way at a time -- never as a LOAD_ATTR_INSTANCE_VALUE cache from one instruction's perspective but a LOAD_ATTR_ADAPTIVE cache from a different perspective. Is that worth worrying about?

Yes, it does make sense to special case LOAD_ATTR_INSTANCE_VALUE_miss.
I didn't properly consider the case where LOAD_ATTR_INSTANCE_VALUE get deoptimised before LOAD_FAST__LOAD_ATTR_INSTANCE_VALUE.

LOAD_FAST__LOAD_ATTR_INSTANCE_VALUE_miss can be simplified by letting LOAD_ATTR_INSTANCE_VALUE_miss do the work.

Something like:

LOAD_FAST__LOAD_ATTR_INSTANCE_VALUE_miss:
        {
            // This is special-cased because we have a superinstruction
            // that includes a specialized instruction. 
            // We execute the first instruction, then perform a miss for
            // the second instruction as usual.

            // Do LOAD_FAST
            {
                PyObject *value = GETLOCAL(oparg);
                Py_INCREF(value);
                PUSH(value);
                NEXTOPARG();
                next_instr++;
            }

            // Now we are in the correct state for LOAD_ATTR
            goto LOAD_ATTR_INSTANCE_VALUE_miss;

This seems misleading. We don't need to push the local here because the jump to LOAD_FAST does it.
Maybe:
"Special cased as this is a specialization of LOAD_FAST, but de-optimization occurs during the following LOAD_ATTR instruction.

I don't think we want to count this as a miss. It is LOAD_ATTR_INSTANCE_VALUE that misses and we don't want to count the miss twice.