For the dynamic model to work we require that the instructions for calling a function must not re-set rounding modes. (If the rounding mode is saved/restored by procedure prolog/epilog, then the program to change rounding mode must typically alter a saved status register on a call stack so that when it is restored, the right modes are established.)
(Here's how Borneo methods work: They do not inherit the rounding mode of their caller. Borneo uses ``rounding'' declarations to control the rounding mode. If a method call appears in a block with a rounding mode, it is the responsibility of the caller to set the rounding mode to round to nearest for the callee before actually calling the method. (The caller must also restore its own non-default rounding mode after the call returns.))
Fully dynamic rounding modes in Borneo are supported by using an explicit setRound that most methods don't guard against, but strictly speaking it is not part of the language. (Methods using rounding declarations use whatever rounding mode the declaration indicates, regardless of the current dynamic mode.)
Of course, it would be an operating system bug if rounding modes as well as the status flags and registers (all the bits, even extended) were not properly saved and restored during OS process switching- processing state must be preserved across context switches, but in languages that support (relatively lightweight) multiple threads, there is a hazard that some of the weight reduction may come at the cost of saving the floating-point state. (Modula-3 requires saving/restoring at thread switches, but in one Lisp system I have used, a designated program, always run at thread-switching time, must be defined to save/restore fp status.)
Two anecdotes
[There is a Matlab bug relating to modes reset during OS context-switches to an HP printer driver: an HP driver used floating-point mode rounding, and did not save/restore. Anyone using different modes got them reset. Defensively, Matlab reset the modes to its defaults at every command, disregarding any user intentions, thereby making it impossible in Matlab to vary the rounding modes!]
[There is also an Intel/Microsoft bug related to crude treatment of overflow of the FP stack: MS uses INVALID exception to signal stack overflow, requiring that it be reset by the stack code, eliminating any realistic possibility of using this for the purpose for which it was intended!]