The comment shuffling has been discussed as well and seems to be as expected. Also I am aware of the discussion, but it did not convince me.
Especially as some things are explained with less diff-noise, but trailing commas are removed, which causes additional noise…
I do not want to restart the discussion though, I just wanted to point out, that the question about formatting is not answered yet.
mix format is to inflexible.
Surely the point is to be as inflexible as possible: after a period of time using a formatter, you simply stop noticing the differences between the format it applies and what you previously did, it just becomes “what Elixir code looks like”
But especially the comment thing is a showstopper for me. I will never accept this as the way elixir is looking like or should look like.
I want to comment a field, so I want to have the comment besides the field, and not 3 lines up, mixed with all the other comments.
Ah, playing around with it now and I see what you mean, that is quite annoying. Looks quite tricky to generalise rules around that from a cursory glance over the formatter code 
You probably have noticed that our stance with the formatter is to be as rigid as possible and then add more flexibility based on demand. Since that initial issue, we have made the comment handling more flexible, to the point there is no reason to not handle it inside structs. Thanks for pointing it out though, I will reopen that existing one.
That’s the pro of trailing commas… unfortunately it comes with cons too, mostly due to optional parens. I am sure we discussed it here but I can’t quite find the link right now. Help? 
Yes!!!
Oh, it already preserves them inside structs in master (from when we made it more flexible). 
At the places where we have a demand for trailing commas, there are no optional parens. We already have used either square brackets for a list or use curlies for a map/struct.
We are not yet at the point where we talk about trailing commas in multiline function calls (which we need to allow at the compiler first and even worse are partially allowed)
See keyword lists without brackets inside function calls.
I said, we are not at the point to discuss those yet, as the compiler currently does not support trailing commas in function calls and those from the bracket-less-KW-lists do only work by accident.
But that’s precisely where the inconsistency is. If we are not at the point to discuss those, then we are certainly not at the point to discuss trailing commas in the formatter. Trailing commas would be straight-forward if it was not for this particular issue.