The trick is to realize that this is a slogan that shouldn’t be taken too literally.
You can easily deadlock a threaded Rust program despite “fearless concurrency”, for instance.
But I think a lot of people will agree that there’s some anecdotal truth to these slogans. I’ve refactored a lot of C, C++ and Rust code over the years, and my experience in most cases the Rust code has worked once it compiles again, and this is definitely not the case for C. (C++ is somewhere between C and Rust).
One of my biggest “A-ha!” epiphanies was when I realized that I could express packaging of programs in a build tool using threads, and I realized that thanks to the enforced ownership model and how the Send trait works, I knew that if it compiled, it would work – and it also happened to fall into the spirit of “fearless concurrency”.
There’s a difficult balance: These types of slogans can be misunderstood, or even misconstrued in some cases. On the other hand, there is some truth to them (even if they have heavily implied context), and we want people to be aware of those potential benefits, without needing to go into several paragraphs of anecdotes to explain the exact details and caveats. Slogans, with all their flaws, can do this. They can get the gist of an idea, and learn the particulars later.
(Note: This isn’t a Rust slogan problem, just think of any slogan you encounter on an average day. “Axe – the best a man can get” .. like .. really?).
In standard library - nope, unless we want to deprecate basically the whole OpenOptions API and rewrite it from scratch.
In general, it's possible with a kind of "typestate pattern" - see this thread for some details. In short, we'll have OpenOptions::append return a new type, like OpenOptionsWithAppend, which will not have create method at all; and similarly OpenOptions::create will return OpenOptionsForCreate, which will not have append. In many cases this makes API too cumbersome to work with though, so, of course, this is all a trade-off (and for me, Rust's power is that it allows such trade-offs on a fairly wide range - that is, I can go wild with typestates and make invalid state transitions uncallable, if I want to, but can also be lazy, bundle everything in a single interface and make sanity checks at runtime).
Offtopic
Well, Rodion Raskolnikov would have a thing to say on this, I guess?
Looking at the python's stdlib this sounds like a horrible idea.
Std cannot "always evolve". Sure you can add new stuff, but it's pretty hard to change existing one, especially existing interfaces.
Moreover some people complain about the "bloat" of third party packages, but imagine if this bloat was forced onto everyone's build due to the stdlib!
IMO a truly constructive feedback would not just ignore existing concerns and reiterate your point, but would instead aim at finding a compromise that solves the issue while avoiding them.
When I started learning Rust, coming from a web-dev background, I found it very strange that std did not have Regex. Especially since there was a de-facto go-to crate for it.
Some time later I learned about the horrors of std::regex in C++.
So yeah, there may be discussions about where to draw the line, but I'm very happy with Rust staying on the conservative side with std.