I don't know why you feel that way. Any major language or standard library change goes through an RFC process, where anyone in the community can submit feedback, and from what I have seen, the official teams are very responsive to concerns.
- The big one is that, at least what I see from my admittedly flawed perspective, there appears to be an active annoyance by a significant number of participants on the various issues on the importance of maintaining library ergonomics under constrained execution environments, with bare metal / free-standing environments being an obvious scenario. An example that comes to mind being stuff dealing with situations where 'global allocation' is actively harmful, which, in addition to happening in kernel development, also happens when building managed runtimes.
- What comes across as an almost begrudging foreign-function interface, no ABI commitments, and lack of clarity about what is undefined behaviour under the `unsafe` operation needed to engage in any of this
- Cargo VS rustc and integration into other build systems. Sanctioned VS unsanctioned paths more generally.
- Prominent people in the community making comments about actively suppressing individual stylistic preferences because it's better for the collective
The rest of the issues you mentioned are being actively worked on or investigated. Yes Rust 1.0 didn't solve all problems out of the gate and even now there's a lot of work still to do. But a lot of progress has been made and is being made.
I get that if you don't follow issues, working groups, zulip chats, etc that it may not be obvious what is and isn't being worked on but I'm really not sure where you're getting this "arrogance" from.
I would argue that this is because there are differences in the severity of the tooling. gofmt for example will not override your decisions regarding line breaks last time I checked, while rustfmt will not afford you any freedoms there.
My understanding is that this is being worked on. Of course any language (or really any project) will have people annoyed that the maintainers priorities don't align perfectly with their priorities.
> What comes across as an almost begrudging foreign-function interface,
I haven't gotten any impression that FFI is begrudging. It really seems like a first class citizen to me, and is certainly better than the FFI story in say, java or go. Rust even has language features that exist just for FFI, such as unions and c-style variadic arguments.
> no ABI commitments
This is a recognized problem. It is also a hard problem, since lifetimes don't exist after compile time. But using the C-ABI is quite usable in some cases. And there have been a few RFCs around this recently (specifically around stable ABIs for vtables).
> lack of clarity about what is undefined behaviour under the `unsafe` operation needed to engage in any of this
This is again a known problem, and something that is improving.
> Cargo VS rustc and integration into other build systems.
I think there was some work being done on this, but I don't know the current status. There are people that use rust with bazel.