Why does shell Command Substitution gobble up a trailing newline char?

Because the shell was not originally intended to be a full programming language.

It is quite difficult to remove a trailing \n from some command output. However, for display purposes, almost all commands end their output with \n, so… there has to be a simple way to remove it when you want to use it in another command. Automatic removal with the $() construction was the chosen solution.

So, maybe you'll accept this question as an answer:

Can you find a simple way to remove the trailing \n if this was not done automatically in the following command?

> echo The current date is "$(date)", have a good day!

Note that quoting is required to prevent smashing of double spaces that may appear in formatted dates.

It's part of the standard:

The shell shall expand the command substitution by executing command in a subshell environment (see Shell Execution Environment) and replacing the command substitution (the text of command plus the enclosing "$()" or backquotes) with the standard output of the command, removing sequences of one or more <newline>s at the end of the substitution.

Of course, the standard is probably written this way because that's how ksh did it or something, but it is the standard, and it is documented behavior. If you don't like it, use Perl or something else that will let you keep the trailing newlines.

Well, it makes sense to me. The newline is only there in the first place, in normal command output, so that the prompt appears after the command completes on a new line. The newline isn't part of the original output in most cases, it's there to tidy the screen up. When you're parsing output from a command the newline at the end is usually troublesome. Why does the wc command output 2 lines of text? Oh, it doesn't, it outputs one followed by a newline. When you parse wc you don't want to be worrying about the fact that there's 2 lines of output - there aren't really, there's only one.