The OpenVZ userspace already works with the same kernel components used by LXC; you can create, start and stop containers on both an OpenVZ and a regular kernel with the same commands.
The commands that don't work are those which don't have the underlying kernel feature to support them yet; as the upstream kernel gains such features, so will the OpenVZ userspace.
So there's not "short-sightedness". OpenVZ and its tooling will live beyond its kernel.
Meanwhile, LXC has already been abandoned by Docker (it's now using libcontainer by default), and others use systemd-nspawn, so what makes you think LXC isn't the short-sighted and soon-to-be irrelevant choice?
Last time I looked, and I did really look, the big picture was OpenVZ and Linux-vServer made it clear they were moving to work through cgroups and namespaces, same as LXC, and will essentially offer little delineation except edge-case features (freeze/thaw/migration/extra security stuff that breaks random programs or requires PhD's in syscall analysis/whatever). These features are questionable in many cases, and if they require custom kernels, they'll never take off as mainstream tooling, even if the projects survive.
By LXC I was referring to IBM's work in general (kernel work mostly) not just to the LXC userspace which has its issues but works mostly most of the time and is defacto standard, due to being first out the gate. Docker for all it's marketing budget can't change history, even with scores of people on its team.
The commands that don't work are those which don't have the underlying kernel feature to support them yet; as the upstream kernel gains such features, so will the OpenVZ userspace.
So there's not "short-sightedness". OpenVZ and its tooling will live beyond its kernel.
Meanwhile, LXC has already been abandoned by Docker (it's now using libcontainer by default), and others use systemd-nspawn, so what makes you think LXC isn't the short-sighted and soon-to-be irrelevant choice?