I was actually thinking something more like this:
You could rename the current filter (let’s call it vtkFooFilter so we don’t have wildcards) to, say, vtkFooFilterSerial (or something else appropriate). Then, create a new class with the original name (i.e. vtkFooFilter). This class has the same interface as the original filter, but it is an abstract class.
Per the rules of abstract classes in VTK, you should be able to call the New method, and the New method will use the vtkObjectFactory to create a concrete class. By default, the vtkFooFilterSerial will be registered with the vtkObjectFactory. However, if VTK-m is compiled, vtkmFooFilter can be registered instead.
Note that this means that any existing code that currently uses vtkFooFilter will continue to work as before. If VTK-m is not installed, when they call vtkFooFilter::New(), it will get vtkFooFilterSerial, which is the exact same implementation as before. However, if VTK-m is compiled, the code will get and use vtkmFooFilter.
Also note that this is exactly how the object factory is supposed to work.
The PV version of the filter (assuming we need a special PV version of the filter at all) simply needs to get a vtkFooFilter as before.