Re: proposed features for branching logic + minimal implementation

[Nora Platiel]

Thanks for the example.

About readability, I think one-liner scripts would benefit the most from 
@{...}, while in multi-line scripts you can achieve decent readability with a 
well indented t/T:
TL1
    ...
:L1

Of course, the t/T alternative requires its own label, and numbered labels are 
annoying to maintain, but that is a more general issue with sed, not limited to 
the t/T command.
When addresses don't cut it we have to use branches, there's no "else" or 
"while" equivalent (but sed is simple and powerful for the right use cases 
precisely because it doesn't try to do everything).

As I said, I think @ is better than t/T, but that is irrelevant since commands 
cannot be removed from sed, obviously.

You used the @ address 8 times, and the J command 5 times.
Currently we are stuck with s/^//;T or tL;:L for resetting the flag. As I said, 
I don't like either.
I looked at t/T usage in my own scripts and I noticed that in *all* cases my 
intent was for the branch to be determined by the last s-command only. (I 
understand that branching on behalf of multiple s-commands may be useful too, 
it just never happened to me.)
In your script, the behavior of all but one of the t/@ is determined by the 
last s-command only. (The @ after label :0 is affected by two s-commands, is 
that intentional?)
Anyway, wanting to branch according to the last s-command only, seems the most 
common case to me, so I think some kind of J command would be very useful, even 
without the @ address. I wish there were more discussion.

As a side note, I noticed that your script has quoted braces inside bracket 
expressions, e.g. [\{\}]. This actually adds the backslash to the list of 
characters, and it's equivalent to [{}\].
Regardless of --regexp-extended, a backslash is not special inside [list], 
unless it's part of one of the sequences listed here:
https://www.gnu.org/software/sed/manual/sed.html#Escapes