(I think there's a mistake here: an ignored file is not a file "under
version control", so `unregistered' should say "not under version
control and not ignored". Would you agree?)
Thanks for pointing out the involvement of find-file-hook and
after-save-hook. The problem you describe is not at all Hg-specific:
vc-state gets called in a context where speed matters, but it's also the
primary entry point for any code that wants to know the state of a file,
some of which might care more about accuracy than speed.
To put it another way, the code assumes throughout that finding out the
file state will always be fast. But it also assumes the information is
accurate if present. This makes me queasy about your original patch.
It does not seem wise to return something we don't know to be true only
on the basis that it all works out fine for now.
The 'nil' return value might provide us with a way out, however.
Could we add an optional argument to vc-state that means "just return
nil if finding out the state properly might be slow"?
Could we make vc-after-save and the relevant find-file-hook entry pass
that option through, and do something sensible with a nil return value?
If they get nil, they would clear out the saved property, and possibly
update the mode line display to "????" or something. Maybe we'd want a
user option (that could go in your large repo's .dir-locals.el, so it's
set-and-forget) to opt-in to not knowing the file state as often.