I have an apology and a correction. sleep_for_framerate does not sleep in any way, it only sets the current room_speed. The bad name is my fault, and I apologize for it. While the function used to be correctly named, I changed it while working on improving the fps-handling, and I must have forgotten to change the name to reflect the new behaviour. The only reason the change you made works, is that the fps-handling system for the platform systems Win32 and xlib are configured to treat room_speed == 0 as being the same as unbounded room_speed. So, with the newest changes, if the room_speed is set to 190, the room_speed will be unbounded. This is buggy behaviour on systems where the fps above 170 worked correctly before. Before on my Windows system, when I set a room to have a room_speed of 213 or 1042, I got a fps of 213 or 1042, respectively. (Note that I have not tested this on a Linux system, primarily because my own Linux box is capped to 60 for whatever reason, but the overall method I implemented for handling fps is the same between Linux and Windows). With the current system, a room_speed of 213 results in a fps of about 1200-1800 (with most values lying around 1780-1795). I have only tested this on my Windows system; on my Linux box, I can at most get an fps of 60. I haven't tried on the same hardware with a virtual box, due to virtual boxes potentially bothering precise fps-handling.
I would also like to note that the current fps-handling system for the Win32 and xlib platform systems are designed to try to gracefully handle slow-downs as well as abrupt stops (like once in a while, a single step taking something like half a second). I designed the behaviour to be similar to that I believe GameMaker to have in this regard; according to my tests, GM also tries to gracefully handle slow-downs and abrupt stops.
Excellent find regarding the room caption; it slows my uncapped system from 1700-1800 to 500-600 when the window_set_caption is commented in. I have added an issue for it on the tracker.
In regards to process priority on Linux, it should be noted that on Linux, a lower process priority value, or niceness value, means a higher actual priority.
Robert, I would also like to request that you ensure that the room_speed can be set to zero in the new versions of LateralGM (if you haven't already done it); I don't think 1.6 of LateralGM allows a room_speed zero, while the system treats 0 as unbounded. On systems where the fps-handling works correctly, there is not really any difference between setting the room_speed to 0 or to a lot higher than the maximum effective fps; however, it seems that on systems where the fps-handling does not work correctly, there is such a difference, given that the newest updates sets the room_speed to zero when the user-set room_speed is above 170.