It's well known issue with badly written build systems which are expecting space to be mandatory separator for tokens in *FLAGS variables. Namely boost-build (but many others, including hand-written). In many cases extra spaces and, especially, new line characters may confuse build systems and lead to strange errors or, which is worse, to silently ignoring user's flags. As proper separation of "extra spaces" from not "extra spaces" in automatic way could not be possible, it's better to explicitly state in portage manual and, maybe, in other sources (like handbook), that users should avoid extra spaces and space-characters in *FLAGS if possible. Please refer #441866 comment 5 and 6 by Jeroen Roovers and consult him for his vast knowledge about this issue.
build systems that die because you happen to have leading/trailing whitespace or multiple spaces in the middle are stupid and broken and need fixing. pushing it off to someone else is wrong.
There is too bugs: this and #442056 Current approach is "just silently fail and let user confused". With bug-wranglers' annoyance of this issue, they seems to be not in mood for explaining users what happened. Instead they are recommending users just to fix their *FLAGS, stating it as it was never supported. This bug suggest to establish this as documented fact - *FLAGS are not supported and it's up to you if you are using them. If you disagree, than please take a look at #442056 - it suggests another approach. That is - it suggests to fail, but to warn user why it could have been failed with possible recommendation to file a bug at upstream's bugzilla. And anyway, it seems that you should somehow reach a common point with bug-wranglers too.
