I see, would a copy-on-write algorithm work? i.e. when a module changes a flag a copy is made and that copy is the one used by the module. The other modules either use their own copy or the global one if they have not changed any flag.
Finally got back to looking more closely at this and developed an experimental version. It appears to work OK (and fairly efficiently) to wrap deterministic calls with a save/restore pair. But the model breaks down for non-deterministic, e.g., labelling, predicates. You can do the restore on exit but need to undo on backtracking to get the desired arithmetic flag settings back.
Maybe there’s a clever way of doing this in Prolog, but it looks to me that this needs to be built into the module context mechanism at a much lower level.
Switching global context during the execution of a predicate is indeed problematic. I think there is an add-on that is like setup_call_cleanup/3,
restoring and re-enabling on non-det exit and retry. That introduces quite a bit of overhead. This has nothing to do with modules. Probably the best solution would be to make the behavior of arithmetic dependent on the module. That requires significant changes though (moving the rounding flags to change the module and provide access to the module context inside arithmetic). This is not entirely new. Most of the flags that affect syntax are also re-routed to modules.
On the short term, setup_call_cleanup/3 is as good as it gets with the remark that arithmetic is non-standard as long as there are choice points on clpBNR open 