It's not exactly documented behaviour, but then the entire thing is an extension. All three commands that were extended similarly (a, i and c) behave the same way: leading whitespace is ignored, and if the text begins with \, then it and the next character (which would be a newline if this were standard-compliant) are discarded. Essentially, it doesn't matter to sed which of these forms are used:

i foo
i \foo
i \
foo

They're all identical. (I know I used i here, but check the the descriptions of a, i and c - it's surreal.)

And the code shows as much:

1111         case 'a':
1112         case 'i':
1113         case 'c':
1114           ch = in_nonblank ();
1115 
1116         read_text_to_slash:
1117           if (ch == EOF)
1118             bad_prog (_(EXPECTED_SLASH));
1119 
1120           if (ch == '\\')
1121             ch = inchar ();

As an example:

$ sed '/test/a \  \nN' <<< test | od -c
0000000   t   e   s   t  \n          \n   N  \n
0000012
$ sed '/test/a \   \nN' <<< test | od -c
0000000   t   e   s   t  \n              \n   N  \n
0000013

The first space after the backslash was discarded, but the next was kept.

It's not exactly documented behaviour, but then the entire thing is an extension. All three commands that were extended similarly (a, i and c) behave the same way: leading whitespace is ignored, and if the text begins with \, then it is discarded. Essentially, it doesn't matter to sed which of these forms are used:

i foo
i \foo
i \
foo

They're all identical. (I know I used i here, but check the the descriptions of a, i and c - it's surreal.)

And the code shows as much:

1111         case 'a':
1112         case 'i':
1113         case 'c':
1114           ch = in_nonblank ();
1115 
1116         read_text_to_slash:
1117           if (ch == EOF)
1118             bad_prog (_(EXPECTED_SLASH));
1119 
1120           if (ch == '\\')
1121             ch = inchar ();