Yes, Virtual Textures and RVTs are different things, althought they both involved tiled-sampling of texture-data (the V in Virtual).
In my experience VTs and RVTs don’t work well together; don’t have one kind feed the other, or another of itself (RVT → RVT).
VTs are more about texture-optimization for larger/more-costly textures on stuff-general, whereas RVTs are more suited for landscapes or painting other kinds of data into to share across stuff-general. When you just need to sample an 8k texture, make it virtual so the system can chunk it up and steam only(ish) the parts that are required vs loading the whole 8k monster. RVTs chunk up whatever stored-data in the same way, only rendering the tiles/chunks needed.
Generally speaking, I’ve only worked with RVTs w/landscapes+heightmesh and VTs on meshes. I’d have to check but I don’t know why on a given mesh one couldn’t use VTs as source and also sample-from an RVT, per the restrictions above. I know you can sample from multiple RVTs onto a single material, so I presume the other is possible as well.
As far as the Megascan material, I don’t have it, but if there is no runtime-virtual-texture sample node then it doesn’t touch an RVT. Otherwise, any nodes set to sample as a VT needs to have the correspondingly sampled texture set as a VT.
And yes, depending on compression of the source texture, and the compression on any RVT, color CAN vary somewhat. Maybe some textures are set as sRGB and other’s not?
Generally, on an RVT it’s surely worth spending the expense on the YbPbr(?) compression; the expensive one. It does a much better job a matching color when sampling in the static mesh.