Regarding using std::variant for polymorphism as a work-around for not having virtual functions: I've often thought there's a bit of a mismatch between how many different derived classes (0 to infinity) an abstract base class can support, versus how many are actually needed in the average user code (anecdotally, 2 or 3 real classes and however many mocks needed for unit tests). Even something like a GUI framework may still have a manageable amount to just compile into something like a std::variant. Theoretically a whole-program analysis could even compile language-level inheritance into something like a std::variant. My point is, this mismatch between how flexible the technique we're using is versus how much flexibility we actually need, maybe indicates that we're not seeing something about how we develop software.

An analogy would be if we used only ball-and-socket joints everywhere in machines, even where a single-axis hinge would work just fine. And then just accepted that machines are inherently wobbly, rather than questioning whether extra degrees of freedom (whether needed or not) are always better than less.

I think sometimes what we really want when we use class inheritance is actually something like a std::variant where we don't have to know all of the constituent types in advance.