Confirmed. Safari TP doesn't have this issue.

It looks this has been done intentionally, below comment explains the reason as 
// Typing spaces at the beginning of wrapped line is confusing, because inserted spaces would appear in the previous line. Insert a line break automatically so that the spaces appear at the caret. 

I do agree the "standard" way of dealing with it is confusing, but I don't think that turning a blank space into a break line on behalf of the user is any less confusing.

This problem arise from an aesthetic fix, first, I'll call a string with no line breaks a paragraph a string with line breaks a multi-line string, and a horizontally displayed string a line.

Rendering a paragraph inside a fixed width container, based on how many characters said width can contain, may leave a line starting with a blank space, which is ugly since it breaks alignment, it seems like the usual way to deal with this problem is to place the extra spaces not in the line that is created due to the width constraints but in the preceding line.

That's what I refer to as "standard" behavior and I believe that's what's being referred to as confusing, and I've seen a related bug in google docs(you can drive the cursor offscreen causing horizontal scrolling).

In my opinion, the desired behavior should be to omit the first blank space to keep alignment, but if more blank spaces are entered, they should be shown in the line created by the width constraint instead of remaining hidden in the preceding line or being turned into a line break implicitly.

Alternatively, looking at SublimeText, the behavior seems to be to treat the last word of the first line together with the following blank spaces as a single unit, which means the last word of the first line will be placed in the line created by the width constraint once the unit(word+following blank spaces) exceed the width of the container.

Looks like a dupe of issue 713969