Perhaps. That's natural in old code that has been in production a long time, otherwise the bug would have been found and fixed by now.
Another case is this from the Search module:
private mapping(string:int) query_profile_names = ([]);
/.../
void flush_profile(int p) { m_delete(value_cache, p); foreach(indices(db_profile_names), string name) if(db_profile_names[name]==p) m_delete(db_profile_names, name); m_delete(query_profile_names, p); foreach(indices(entry_cache), string id) { array ids = array_sscanf(id, "%d:%d"); if(ids[0]==p || ids[1]==p) m_delete(entry_cache, id); } }
Here m_delete(query_profile_names, p) is causing a compilation error in 7.7 since the mapping isn't declared to allow ints as indices. Assuming that's correct, the m_delete is just a NOP at runtime. What the intended behavior is here I don't know, but from a compatibility perspective there's a bit of difference when code just has no effect at runtime and when it doesn't get through the compiler.
Furthermore, even if the bug renders a specific function completely dysfunctional, the module should continue to compile; the function might not even be used at all in the end. So there's no real point in discussing how likely the code is to work in spite of the error; a new compilation error introduces a compatibility problem regardless. That's why I'm convinced compatibility checks needs to be done for each and every new error added to the compiler.
If that's too cumbersome then we could instead reduce all errors to warnings in compat mode (that is, all errors where the compiler still can generate output). That might be a bit unfriendly to those who are forced to develop in compat mode, but it's better than the alternative (i.e. that the compat system doesn't work).