MSVC Compiler Error C2688: Microsoft C++ ABI corner case issue?

MSVC Compiler Error C2688: Microsoft C++ ABI corner case issue?

A very specific corner case that MSVC disallows via Compiler Error 2688 is
admitted by Microsoft to be non-standard behavior. Does anyone know why
MSVC++ has this specific limitation?
The fact that it involves simultaneous usage of three language features
("virtual base classes", "covariant return types", and "variable number of
arguments", according to the description in the second linked page) that
are semantically orthogonal and fully supported separately seems to imply
that this is not a parsing or semantic issue, but a corner case in the
Microsoft C++ ABI. In particular, the fact that a "variable number of
arguments" is involved seems to (?) suggest that the C++ ABI is using an
implicit trailing parameter to implement the combination of the other two
features, but can't because there's no fixed place to put that parameter
when the function is var arg.
Does anyone have enough knowledge of the Microsoft C++ ABI to confirm
whether this is the case, and explain what this implicit trailing argument
is used for (or what else is going on, if my guess is incorrect)? The C++
ABI is not documented by Microsoft but I know that some people outside of
Microsoft have done work to match the ABI for various reasons so I'm
hoping someone can explain what is going on.
Also, Microsoft's documentation is a bit inconsistent; the second page
linked says:
Virtual base classes are not supported as covariant return types when the
virtual function has a variable number of arguments.
but the first page more broadly states:
covariant returns with multiple or virtual inheritance not supported for
varargs functions
Does anyone know what the real story is? I can do some experimentation to
find out, but I'm guessing that the actual corner case is neither of
these, exactly, but has to do with the specifics of the class hierachy in
a way that the documenters decided to gloss over. My guess it that it has
to do with the need for a pointer adjustment in the virtual thunk, but I'm
hoping someone with deeper knowledge of the situation than me can explain
what's going on behind the hood.