Maybe it is just a wrong perception, but I think it wouldn't hurt to improve the evolution process itself.
Let's take SE-202 as example: It's not a tiny change, but I don't think it was overly complex.
Still, despite a long review period, we now have discussions about two amendments (SE-0202 Amendment Proposal: Rename Random to DefaultRandomNumberGenerator and Proposed amendment to SE-202: Replace `Collection.randomElement` requirement with `randomIndex`) which have been started after formal acceptance.
Apparently, it can be very hard to get things right at the first try, but I don't think it should become the norm to change decisions right after they were made.
I also have the feeling that formal acceptance often takes quite a long time, and maybe that is because people want to avoid amendments, or fear to oversee problems which possibly can't be addressed later because of stability concerns.
But imho at least for purely additive proposals, all this stress isn't necessary:
Just like we have deprecated API that shouldn't be used because it's going to be removed, we could have API that is experimental and should only be used by those willing to accept breaking changes.
Another possibility to improve Swift in a more informed way just appeared with the TensorFlow branch, which has some features that aren't in the official release.
Instead of integrating those asap, we could use the opportunity and wait for some real-world experience and change details accordingly.
Afaics, no one can really be sure what we will think about