b and c are probably the options possible. b is done in Ichiban and Tau.
As for an unbounded max_arity, yet an error for too large arities of procedures, there are three systems: SWI, YAP, ECLiPSe. ECLiPSe produces an uncatchable, non-conforming error, YAP has its own non-conforming error class embedded in a conforming error/2. Only SWI produces representation_error(max_procedure_arity).
The question is only who needs to know about max_procedure_arity. In particular in systems that do not have this problem since they have a rather low max_arity. 255 seems to be most popular.
Making such a change for one system seems a little bit exaggerated. In particular given than in 14 other systems there is currently no advantage.
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/max_arity
But now, assuming this gets added. One possibility could be to add an implementation defined Prolog flag max_procedure_arity, to make this discoverable. And to demand nothing from a system where max_arity is good enough. Nothing except accompanying documentation. Maybe.
In any case, quite related is
?- current_predicate(p/1000000). false. % 8.8.2.3 representation_error(max_arity), unexpected. % SICStus, GNU, Minerva, Cx type_error(predicate_indicator,p/1000000), unexpected. % X, ECLiPSe, Ciao