No again, there is no framerateconversion when generating proxies, no resampling, optical flow or whatever. See it as generating a still images sequence, each frame of original footage generates an image. The image sequence gets only a flag 24fps but will by played with 60fps or whatever the projectframerate is.

You're describing the type of video stream copy done to re-mark slow motion video shot at super high frame rates. But to make a proxy, changing the frame size is also required. Which is impossible without decoding, resampling, and recompression. If it was as easy as a stream copy, processing time would be faster than gluing camera clips together into a single uninterrupted clip. I just did that to a 3-hour Xdcam 422 shoot I'm working on and ffmpeg knocked it out at 1200 frames per second. And that included remapping a pair of mono audio tracks into stereo. Be nice if proxies could be made anywhere near that quickly.

I think we might be taking this thread sideways. Everyone knows that Vegas proxy generation is a problem and the only relevant issue is finding the best way to deal with it.

Actually since I upgraded to the PC in my signature, I haven't use proxies anymore. My footage is 2160p50 AVC and 1520p50 HEVC.and plays smooth at preview best full. For some complex parts I just use the prerender option which is also very quick to use in Vegas because it uses your GPU.

Proxies are just a tool for editing 4k footage on a PC not having the specs. When the time for proxy generation is that important for your production, better get a new PC. It saves you proxy creation and finally rendering time.

I found a simple way to generate the proxy using FFMPEG, since version 20, Vegas has become much more tolerant in the encoding parameters for sfvp0 files.
Just set the encoding and container to the mpeg2 standard, currently it does not check the XD-CAM branding and therefore accepts more flexible parameters.
I have generated the proxies this way and the program, even when running the project, immediately identifies the generated proxy.
Use the following encoding parameters in FFMPEG:

ffmpeg -i "input.mp4" -c:v mpeg2video -brand mp42 -vf "scale=iw/1.5:ih/1.5" -qscale:v 2 -an -f mp4 "output.mpg"

Currently, Vegas no longer uses the audio in the proxy file, instead using the audio from the original clip, which is why I use the "-an" parameter to exclude the audio.

I also set the scaling equation to generate files with half the dimensions of the original, and the quality "-qscale:v 2" (the lower the number the higher the quality) seemed good for editing purposes.

But from what I've been experimenting with here, as long as the container and encoding are mpeg2, the other parameters can be modified at will and will continue to be recognized by Vegas.

Once the "output.mpg" file has been generated, it can be renamed to "input.mp4.sfvp0" and Vegas will immediately accept it as a proxy.

These operations can be done in a batch file to facilitate the process.

I recommend (after installing ffmpeg) to use the free Python application "PyWin Context Menu" to create a context menu on right mouse click and associate the file with a batch file.
https://github.com/VodBox/pyWinContext

I'll leave here the batch file that I use to encode and rename my clips:

set i=%~n1
set x=%~x1
set o=%i%.mp4
if exists %o% (
   set o=%i%.mp4.mpg
)
ffmpeg -i "%i%%x%" -c:v mpeg2video -brand mp42 -vf "scale=iw/1.5:ih/1.5" -qscale:v 2 -an -f mp4 "%o%"
ren *.mp4.mpg *.sfvp0
exit

Save it with any .bat name and associate it using PyWin to make the proxy files.