>On 2012-03-29, Aharon Robbins <arn...@skeeve.com> wrote:
>> 1. The default handling of backslash in sub() and gsub() has been reverted to
>>    the behavior of 3.1. It was silly to think I could break compatibility that
>>    way, even for standards compliance.

>It's silly to tie your hands behind your back thinking that you have no way to
>confront such a thing!

>There are ways to manage language transitions like this; just not "cold turkey",
>obviously.

>What you can do is mark some features as obsolescent and give the users the
>time and the tools to flush users of those features out of their code bases.

>For that, you need better dialect control and diagnosis options.

>You have --traditional (which is useless for this purpose) and --posix,
>which is useless also because it disables all extensions (cannot be used
>by users who are programming in the GNU awk language).

>You need something like, say, --progressive which provides backward
>compatibility with earlier gawk releases (and supports all extensions), but
>with warnings about things that are going to change in a future version. This
>can be used by GNU awk programmers to have a "heads up".  In the default mode,
>the support for obsolescent behaviors can endure much longer (perhaps forever),
>but under --progressive, undesireable things disappear in a couple of years.

>Under --posix, you can make the changes cold turkey (at least for anything
>which fixes a POSIX nonconformance).  If the user wants posix, hit them with
>it, and don't bother warning that you made a quiet change.

>--posix is for people porting among awks.  They are best served by just
>moving forward in conformance.  If they are stepping on something that is
>broken in gawk, they will likely find it when running with other awks;
>and likewise they just expect something that works right on other awks
>to just work right.