Thank you for your input!
I know that you can fix timesteps in MonoGame, but the problem wit that is that is also limiting the rendering, not just the Update() calls. I really would not like to restrict the player to play the game with only 30 FPS just have a 30 FPS physics update in my game. Even a non-gamer can clearly tell the difference between 30 and 60 FPS rendering and a seasoned gamer can spot even finer differences. In fact, I would not like to limit them in any way, if they paid for a rig that can produce hundreds of frames / second, let them enjoy it Also, even if you restrict your game to 60 FPS using the MonoGame method, you might still want to have less physics update to save on the battery on mobile, for example.
With “my” method, the drawing is unaffected, for example on my PC, my small platformer game demo runs with around 2000 FPS, while the physics update is only 30 FPS, the rest is displayed with interpolation. Not that it matters so much, because I have a 144 Hz Monitor, so it won’t display more than 144 frames / second, but for stress testing, it’s really nice to see how the game runs, it really gives you an idea of how the code performs.
My personal recommendation is not to limit the FPS in MonoGame, or just include an frame limit option in your game settings, and the users can decide for themselves, so they can still enjoy smooth gameplay, and fix the timestep for the physics updates.