[SOLVED] Odd catch/match sed behavior

Issue

Why does GNU sed not catch as expected below in [1], while [2] and above all [3] are OK?

[1] $ echo "ca t" | sed -E 's/c([^ ]+) /\1/'  # Odd, expected 'a' or possibly 'a t'
    at
[2] $ echo "ca t" | sed -E 's/c([^ ]+)/\1/'   # OK, expected 'a t' 
    a t
[3] $ echo "ca t" | sed -E 's/ c([^ ]+)/\1/'  # OK, does not catch, but then why on earth is [1]?
    ca t

Try as I might to browse the GNU info on regexps for sed, I still cannot make sense of this output in [1].
The blank space at the right of the first part of the substitution regexp in [1] was expected to block expansion of the catch just at the space in between a and t, yielding a as a match.
Supposing this rightmost blank space in the first-part regexp actually does not count for some reason unclear to me, I expected the match to behave as in [2], yielding a t.
But then [3] shows that blank spaces do act as contextual filters for the match, as a leftmost blank space added to the first-part regexp blocks any match.
sed version is 4.7 under Ubuntu 20.04.
I sure must be missing something somewhere. Any idea?

Solution

In [1], the regex c([^ ]+) matches ca capturing a as \1, which means the substring ca is replaced with a and the pattern space will turn into at.

In [3], the regex c([^ ]+) does not match the pattern space due to the leading space and the pattern space is printed unmodified.

I hope my explanation is clear enough.

Answered By - tshiono