This is obviously questionable, as it requires reaching into Wine internals in tests (beyond simply detecting whether Wine is in use).
However, we are at a point where, for d3d10 and above, the Vulkan renderer works well enough in general to see real use [in fact, in my experience it usually works better than the GL renderer], and at this point I think avoiding regressions is quite important. It is currently difficult to run tests with it when the results contain so much noise, and I think we need to solve this problem, by actually marking which tests work on each backend.
We could in theory expose the renderer through some adapter string, but I believe in the past applications have been sensitive about the contents of adapter strings.
Fixing either renderer to reach and maintain parity is not feasible. The GL renderer is not going away, but regrettably GL as an API is abandoned by Khronos, and important features we need in order to implement some Direct3D features will probably never be introduced into GL. Moreover, the amount of effort that would be required to reach parity is not small, and itself would all need to be verified manually.