I’m not 100% sure I completely understand all of that, but I can offer a few thoughts. Everything @rempesm said is true, I just want to add a couple points.
Vector monitors with a bandwidth higher than 10 MHz don’t exist, but XYZ oscilloscopes do. I have one that has 30 MHz on the Z axis. But it’s a moot point if the dot size is too large relative to the screen size. That’s the limiting factor for the vector display part of the patch.
HD ramps will give more detail than SD ramps. This is a big aesthetic difference, because SD ramps will more clearly “delineate” the lines of the raster. In my experiments with HD ramps, I’m getting much softer, ethereal, gossamer translucency rather than visible scanlines. The raster is rendering much more as a surface than as a bunch of lines. But this is also dependent on your settings. Suffice to say that an HD ramps setup can achieve some of the characteristic “looks” of an SD setup, but not so much the other way around.
In my experience, the performance of TBC2 as an up/down converter leaves something to be desired. I’m seeing it drop frames all over the place. So in any event, I recommend keeping everything in the system in the same format: camera, decoder, and encoder. As @rempesm points out, the Visual Cortex is the limiting factor here. ESG3 or Chromagnon is what you need if you’re trying to get more detail in the final product.
Also, a genlock setup is preferable to wild sync into TBC2. I’m getting frame tearing. A camera genlocked to TBC2, or a whole system genlocked to the camera via a Syntonie decoder, should solve the frame tearing issue. I guess this might also work by sending a copy of the camera’s composite or Y signal into the TBC2 Sync input? More experimentation is needed.