As long as all VTK classes derive from vtkObject, internally reference count, and disallow direct invocation of the constructor it seems to be of limited utility to try and make the VTK specific pointer classes behave as if move semantics are necessary. You can only create a VTK class instance as a pointer, returning a vtkNew and moving to a vtkNew or vtkSmartPointer is nice, and offers unique_ptr like behavior.
At the end of the day vtkObject derived classes are primarily pointer based, and if I assign a vtkNew owned object to a vtkSmartPointer its life will be extended beyond the vtkNew even without any move. I am a big fan of using smart pointer classes where reasonable, but without much bigger changes to the VTK inheritance hierarchy it looks like a lot of work and API churn with limited returns. If VTK wants to make bigger changes is it worth reconsidering whether internal reference counting still makes sense, whether we could allow directly calling the constructors/destructors, and relax everything deriving from vtkObject. These are pretty huge changes, the community may not want to take that step, but it would let us use the STL more naturally.
It would be pretty sad to go back to not implicitly casting vtkNew to T*, if we are trying to create a thing to return more safely from factories maybe a fourth class such as vtkUniquePointer could serve that purpose without causing churn in the rest of the API? I think not having that implicit cast limited adoption of an otherwise very useful smart pointer for many years. My $0.42…