= is not valid for Base64 when located in the middle of an input string. As such it will be ignored (since $strict is not being used) and PHP will attempt to decode "TGluZSBuciAxIGJjZGVmZwoTGluZSBuciAyIAo=".
The line feed is irrelevant.

What is this "may occur as input from an email"?

The case is:

The email program will produce the email body as a valid base64 block and concatenate the selected signature as a separate valid base64 block. Thus the email body will consist of two valid base64 blocks.

Using the linux base64 program this body is decoded correctly.

As we are using a PHP script to interpret emails from different sources, this base64_decode behaviour is highly inconvenient and I don't see, why it cannot decode consequtive base64 blocks correctly instead of the current partly corrupted way.

your mail client properly deals with mime-mail which is *highly* complex especially when it comes to nesting

Please, understand, that we are handling emails sent to a server from the outside world composed by a variety of email clients out of our control. The emails are handled by a PHP program handling incoming emails as input to a special service.

Please, relate to the fact that the linux base64 program is handling this case correctly, whereas base64_decode is corrupting data. There is absolutely no reason for this difference. Correcting it does not cause any backwards compatibility problems, as I assume nobody is using base64_decode for generating partly corrupt data.

> Please, understand, that we are handling emails 
> sent to a server from the outside world composed 
> by a variety of email clients out of our control

please understand that everybody dealing with email has that issue and solving that properly is far outside of a naive usage of base64 / string functions

it's far outside of the scope of a programming language 

you are wrong here - look how mail-clients linke rouncube written in php deal with emails! again: you are wrong here, base64_decode alone can't handle emails, period

Please, forget the source, and relate to the problem.

Linux base64 is handling decoding correctly.

base64_decode is not handling it correctly, but corrupting data.

again: read the source of roundcubemail which is written in php and solved your issues

base64_encode() is supposed to decode a base64 encoded string. Two
concatenated base64 encoded strings are not a base64 encoded
string.

The base64_decode is handling the padding character '=' incorrectly.
It can decode concatenated blocks if the statement 
i = 0;
is inserted into the code in a proper place.
However, adding a few more lines will handle it properly and I am currently testing this.

argue whatever you want: "Concatenated base64 blocks" are idiotic

I may agree, but I am relating to a world outside my control, not an ideal world.

I just uploaded a patch as well as a test script (for 8.0.3)
There should be no change in the old behaviour for single base64 blocks.

What if the first block isn't padded with '=' because the data it's encoding is a multiple of three bytes in length?

$s1 = base64_encode("Line nr 1 bcdefgh\n");
$s2 = base64_encode("Line nr 2 \n");
$str = $s1."\n".$s2;
echo $str;
echo base64_decode($str);

No problem. One might add these test cases to the test script uploaded to check for this case.

'Line nr 3ab Line nr 2a Line nr 1 :TGluZSBuciAzYWIg TGluZSBuciAyYSA= TGluZSBuciAxIA==',
'Line nr 3ab Line nr 3ab Line nr 1 :TGluZSBuciAzYWIg TGluZSBuciAzYWIg TGluZSBuciAxIA==',

CODED=TGluZSBuciAzYWIg TGluZSBuciAyYSA= TGluZSBuciAxIA==
 UNCODED=Line nr 3ab Line nr 2a Line nr 1
 UNCODEDSTRICT=Line nr 3ab Line nr 2a Line nr 1
CODED=TGluZSBuciAzYWIg TGluZSBuciAzYWIg TGluZSBuciAxIA==
 UNCODED=Line nr 3ab Line nr 3ab Line nr 1
 UNCODEDSTRICT=Line nr 3ab Line nr 3ab Line nr 1

So the job of could be done with a few lines of PHP code; if you want to play code golf you could get it in under 100 characters, but for real-world usage a few lines would be better.