?- current_prolog_flag(F,Version),sub_atom(F,_,_,_,version),current_prolog_flag(max_procedure_arity,A).
A = 255,
F = version_data,
Version = ciao(1,25,0,commit_info(master,b868c430bd7e2997db8672f2f85c432c3dfc7ab5,'2026-03-05 18:53:14 +0100','1.25-v1.21-1934-gb868c430bd')) ?
So now you have added this flag, even if in your implementation
max_arity would be good enough.
We added it months ago, when we raised the compound-term arity limit;
there was some discussion at
https://discourse.prolog-lang.org/ before
we decided. Since then max_arity and the procedure limit no longer
coincide (we genuinely have two limits now) so max_arity alone cannot
report both.
I very much doubt that other currently conforming implementations
are willing to add that flag, which to them is useless.
On the head-count, I'd gently note that "unbounded terms, bounded
procedures" is a direct consequence of the execution model that
traditionally makes systems fast. SWI, YAP and ECLiPSe (and now Ciao,
arguably Picat/B-Prolog too) arrived at it independently, from the
same constraint. So it is not unreasonable that a system with a single
255 limit would find the flag useful the moment it raises its
compound-arity limit, which is exactly what happened to us.
Codifying that max_procedure_arity specifies that restriction
*in case it is present* seems to be good enough. That means,
that other implementations are now restricted in the sense
that if they add that flag, it must have the current meaning,
so they cannot use that flag name to mean something else.