Regarding standard library inconsistencies... can consistency be brought to some nearish-term future release, like R20 or something, which brings much needed consistency to OTP while providing temporary backward compatibility through reordering shim functions + guard clauses?<p><pre><code>  split(List, N) when is_integer(N), N &gt;= 0, is_list(List) -&gt;
      split(N, List);
  split(N, List) when is_integer(N), N &gt;= 0, is_list(List) -&gt;
      case split(N, List, []) of
	  {_, _} = Result -&gt; Result;
	  Fault when is_atom(Fault) -&gt;
	      erlang:error(Fault, [N,List])
      end;
  split(N, List) -&gt;
      erlang:error(badarg, [N,List]).
</code></pre>
It makes the ordering inconsequential in this case... which I can see as a sort of transient bad thing.<p>You could also straight up migrate the API and provide a set of compatibility_mode parse transformations to be included which would take old-signature invocations and replace them at compile-time with the new ones, forcing really only a build-phase change to existing code bases until they make the change on their own.<p>I dunno.  It&#x27;s been an annoying problem for a long time and a common complaint amongst newbie Erlang developers, but I guess at the end of the day you just get used to it, so as you get more experienced you probably just care less about it.  That said I&#x27;d love to see better adoption of Erlang, and &quot;simple&quot; things like this might assist with that.<p>Lower barrier of entry to the stages of scaffold-project -&gt; write -&gt; build -&gt; test cycles is one of the things that&#x27;s really appealing about Elixir by comparison.<p>Is this kind of thing of any interest at all to Ericsson to accept upstream if the community were to go through the drudgery of combing the stdlib for the places these changes should be made and providing options for transition&#x2F;deprecation paths?