Honest question: which one is unintuitive?

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.

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 canonical notation is like this:

  func(arg1, arg2, arg3)

the first example splits it across multiple lines in a way which maximally preserves the other apects of the notation.

> 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).

That’s what many auto formatter do anyways, even ones setup for fixed width fonts.