yes, that's why it's dangerous and it's likely that you miss versions strings. you should not depend on this and break the protocol this late.
I have to agree with Markus here. Implementations may wish to maintain information about noncompliant implementations, but that should never be required or even suggested as a way to implement the protocol correctly.
Given a choice between "do X unless the peer is broken, in which case we do Y, which works with all peers" and "always do Y, which works with all peers", the first is only acceptable if there is a pretty compelling reason why you'd want to do X.
In the present case, there is a clear way to specify the extension such that a correct implementation will work with existing implementations that do not support the extension, regardless of whether they can handle extra fields in the KEXINIT packet -- don't send any such fields, and trade a second set of messages instead.
Of course, we do still need to update the transport document to specify that its implementations MUST NOT consider the contents of the reserved field in deciding whether a KEXINIT packet is valid, but MUST include its actual contents in the hash anyway. Fortunately, it sounds like all the existing implementations behave this way anyway.
-- Jeff