I think I'd prefer to leave code that doesn't use overlayworkingctx unchanged. I don't see any reason to get the merge state from the context if we know that the context is a regular workingctx.
As long as we do repo[None].mergestate() it will not be more or less right than before. We'd at least want to refactor the code so it creates a wctx instance early on and then reuse that as much as possible, so we could later replace the wctx = repo[None] by wctx = overlayworkingctx(...). In cases like this one (checking for unresolved merge conflicts), it will never make sense to do that on an overlayworkingctx. I'm very much in favor of making more things work "in memory" where that's reasonable, but I'd prefer to leave callers unchanged until we actually try that in earnest. I think we have a similar situation with the dirstate and I don't think we've tried to hide all access to the dirstate bethind the context objects.
I view overlayworkingctx as something that exists for creating commits without touching the working copy and without caring about the working copy state. In the code here, we explicitly care about the working copy state (because we're going to modify it).
Ah, interesting. That angle hadn't occurred to me. I don't think I'm wholly convinced, but maybe we need an explicit mechanism for "get the wdir" as contrasted with "get a context for the wdir".
I think I'll at least remove this patch from the stack for now...
I had to look at my own patches: overlayworkingctx uses the in-memory mergestate, workingctx uses the on-disk one. repo[None] returns a _workingctx_, not an overlay one, so I'm confused what the issue is here.
This is stalled. I've got some bugs in the logic I can't track down and
this is second on my priority list at work. I do intend to come back to it,
but it'd be fair to mark it all as changes requested.