This issue is due to *drop_whitespace* arg being True by default.

Documentation states that *drop_whitespace* applies after wrapping, so the fix in the PR would break that promise because, as far as I understand, it applies the wrapping after *drop_whitespace*. (Irit's comment on the PR refers to this).

I feel like the behaviour in the PR is more logical and probably what most users would prefer and need in most cases. But it's a backwards compatibility change of behaviour that's not buggy.

'foo                  bar'
# wrap for width=10
['foo','bar']  # current behaviour
['foo bar']    # more intuitive wrapping to width=10

As I was looking at this, I thought that wrapping with drop_whitespace=False would surely be stable. Not so!

It looks like the logic assumes that \n needs to be replaced by a space for cases like 'foo\nbar', which makes sense because otherwise two words would be joined together. But with drop_whitespace=False, repeated fill() calls will keep replacing \n with a space and then adding a new \n to split lines again:

      original: 'xxxx xxxx xxxx xxxx xxxx.  xxxx'
       wrapped: 'xxxx xxxx xxxx xxxx xxxx.  \nxxxx'
 wrapped twice: 'xxxx xxxx xxxx xxxx xxxx.   \nxxxx'
wrapped thrice: 'xxxx xxxx xxxx xxxx xxxx.    \nxxxx'

Further, a newline with a nearby space within the requested width will be converted to two spaces:
'a\n b' => 'a  b'

I don't know if the original issue is worth fixing or not, but I think the issue shown above would be good to fix.