In circumstances, and depending on configuration, the code formatter tool may still aim for alignment, such as assignment operators on subsequent lines. Whether you like that or not, for me the question still stands: how does that jive with "almost monospaced".
Viewing the examples generally, the second one better communicates hierarchy at the cost of an extra line. The arguments are all grouped together visually and without distraction, while in the first example the first argument gets muddled with the function name. Why? To save a line break?
> the first example splits it across multiple lines in a way which maximally preserves the other aspects of the notation.
Once you’re splitting it across lines I don’t think that is a desirable attribute. Better to use a format that suits multiple lines than attempt to match as closely as possible to a format intended for one line. Like those “flying cars” that try to look like the “canonical” car.
From my perspective this is a UI problem (though not a serious one).
Why? The purpose of code is to be readable to humans.
At the same time I get your point and also the argument about Git diffs (which also should be readable). So maybe the ideal situation would be a separation of code and its formatting, so that we have more options than tabs and also no need for crutches like tabs. Like a better, more flexible code formatter that lets you display and edit code in the editor using one style but then saves the file in a standard format that's consistent across the whole project.
It should ignore "almost monospace". Most projects have multiple developers, you should assume different developers have different IDE/font preferences, so your formatting shouldn't try to cater for it.
I just put stuff on one line and let the editor wrap them. Doesn't waste vertical space, compatible with any font, any size, any window width, any form factor, the best from all worlds.