I find this is a dangerous and somewhat misleading way of arguing. UB is not defined by what some platform or backend happens to do. There is an import intermediate step here that you are skipping. (FWIW, I am not saying you don't understand this distinction, but you are failing to communicate it and that makes it very easy to misunderstand your statements.)
That example I brought up is an example of failure to realize that Rust programs don't run on x86, they run on an abstract machine. That machine has rules for what you are and are not allowed to do, and violating those rules (violating the "contract" of the abstract machine) is what we call UB. The reason the program is wrong has nothing directly to do with compiler backends or platforms. The program is wrong because it violates the contract of the abstract machine.
Compiler backends and platforms come in when we ask why the abstract machine is defined the way it is -- but they are not the only considerations coming in, and we should be very careful not to fit this definition too tightly to whatever happen to be the current optimizations and platforms. Being able to understand, analyze or test programs on the abstract machine are other considerations coming in here, and they are IMO just as important.
Sorry if this came across wrong, I did not mean to suggest you do. The comment was in reply to yours, but not directed only at you. This entire thread is about a crate that knowingly causes UB and got broken when the compiler's behavior in face of this UB changed. That's the kind of "laiseez faire" attitude I was referring to.
(FWIW, I didn't say anybody was against RFCs, I just suggested some people think an RFC is not necessary because we can just do unwinding across FFI barriers and it just works, even though it "technically" is UB. I guess we all sometimes overinterpret other people's statements.)
That is not what I meant to say, and I am sorry for not communicating more clearly. As mentioned above, I was responding to the entire thread, not just to your post.
What I meant to say is: people (not you specifically!) clearly thought that unwinding across the FFI edge is a feature supported by Rust. However, it is not, there is no RFC specifying it, and the fact that this happens to "work" nevertheless does not magically mean that Rust has a feature that was never specified.
What you are saying here sounds a lot like "there was a working feature and the Rust team wanted to take it away" (and if that is not what you wanted to communicate, I am sorry -- but also please consider why this is the interpretation several people get when reading your posts). But that's not what happened. There was no feature that got removed. The only change is better UB linting being turned on by default for all builds, and we should never be in a situation where that upsets anyone.
Nothing the Rust team did indicated that Rust never should support unwinding across an FFI edge. In fact, there already is an unstable #[unwind] attribute. All that happened is that UB got turned into a safe abort, taking away the possibility to pretend that Rust supports FFI unwinding. This changes nothing about the possibility of actually adding FFI unwinding as a feature, having a way to tell the compiler that this is happening (to suppress the abort-on-panic) and specifying the conditions under which this is allowed.
While I agree in principle, I think it is also important to be emphatic with programmers that want to get something done, and there just is no way to do it without causing UB. While the "right thing to do" is to get the definition of UB changed, that can seem like a insurmountable obstacle. I can understand why people take shortcuts. But I don't have to be happy about it, and I think it is important that we communicate clearly why we think programmers should go through the extra effort of finding or creating a UB-free way to do what they want to do. We can point at this thread as an example. 