This entire post is confusing something very basic - Physical storage and construction concepts that are built in to C/C++ do not (and can not) correctly interact with any polymorphic OO concepts. The entire reason for factory patterns is because you can't go around constructing and copying physical objects and expect any manner of intelligent OO to work. Repeat after me, polymorphic class libraries are NOT COMPATIBLE with conventional C/C++ construction/copy semantics. Instead, you must use virtual functions (aka interfaces you are in control of) to define whatever contracts your LSP classes want to implement, and then do so.
Construction was ALWAYS special in OO. It is IMPOSSIBLE to construct a derived class object of type "Baz" without someone, somewhere knowing how to do so explicitly. So why would you expect a client to be able to invoke non-virtual, non-polymorphic methods that could possible make sense and interact with OO concepts such as LSP.
For this reason, it is often (but not always) best to isolate your designs into 2 types ...
A) Those that are intended to be polymorphic contracts, where the work is destined to be decided by derived classes - in which case abstract base classes / interfaces would prevent this type of misuse completely.
B) Classes that are more traditional / implementation oriented (aka not designed around polymorphism), which would implement their own API usually as non-virtual method. Which doesn't preclude inheriting from them, nor overriding their methods, but does preclude expecting the behavior to be polymorphic.
Since B is a slightly strange concept, I'll give you a real world case I had. I had a Point2D class, which was non-polymorphic. I then had a Point3D class, which inherited from the Point2D class, adding the Z value of course. The point wasn't to polymorphic get 3D behavior from a 2D client, the point was just simple implementation sharing and auto-casting. After using it for a while, I actually decided the auto-casting was honestly a mistake - since truly to "get" a 2D point from a 3D point you should choose which "plane" you want (ie xy, xz or yz, or even some other non-right-angle 2d projection into your 3d space).
As I'm sure most of you are aware, containment, or even non-public inheritance is often a better answer for "B" style situations.
Now if only C++ (and C#) had a syntax to write 1 line to "forward" all of an "interfaces" methods on to a specific contained object, instead of having to write each wrapper function manually. I could rest in peace.