Two more comments on Jose's suggestion to add max_procedure_arity.
1mo, what if a goal with higher arity is called in such a system? As such a predicate cannot be defined, an existence error seems to be most appropriate. Much in the same way that current_predicate/1 also fails for very large arities. I added this case as #13 to https://www.complang.tuwien.ac.at/ulrich/iso-prolog/max_arity
Currently, Trealla and Shumway do produce an existence error, whereas SWI produces a representation_error(max_procedure_arity). The question is only what has to be represented to justify this error, when at the same time, current_predicate/1 silently fails?
ECLiPSe produces a non-standard error, and YAP an instantiation error, unclear why. All other systems have no restriction (Ichiban, Eye, Tau) and thus produce an existence_error as well, or just have a bounded max_arity.
2do, the impact this extension has on conformity of existing applications. Code sometimes probes a system for certain properties in order to ensure conformance. To ensure that the arity is bounded, it is (up to now) sufficient to ensure:
?- current_prolog_flag(max_arity, V), integer(V).
which holds for SICStus, Scryer, GNU, X, IV, B, IF, Minerva, Cx, Flowlog, Ciao, and XSB.
If the standard would permit adding the new flag max_procedure_arity even in the case of a bounded max_arity, above probe would become invalid. Which means that applications that were so far conforming are all required to probe for max_procedure_arity.
One fix to this seems to be to permit adding max_procedure_arity only in the case max_arity is unbounded. And that seems to be the actual reason for having this flag in the first place. Code for Ichiban, Eye, and Tau seem to be the only systems were their probing now also would require probing for max_procedure_arity. Given their young age, this does not seem to have the same impact as for systems with 30+ years of declared conformity.