I think Boat's Not Explicit or Aaron's reasoning footprint posts are great examples of ones that aren't about a proposal at all, but about how to evaluate proposals.
For example, from the former, needing to write Ok( repeatedly sounds like "Manual" to me. And from the latter, it's low-impact on Applicability (there's a "heads-up" -- try -- that it's happening), Power (still type-checked, only applies to the final value, no control flow changes, just a wrapping), and Context-Dependence (the only place to look is the return type, and using a different type there -- like Result<T> vs Option<T> -- doesn't actually change what you can write in the function body with try any more than it did without it).
I'd be happy to read a blog post that introduces another such metric and shows how try fn doesn't follow it, but other existing choices in Rust do.
The problem I had with post 35 is that even where I agreed in the abstract, I didn't agree in the specific.
For example, I agree that there shouldn't gratuitously be two ways to do the same thing. But with "There are these 2 very differently looking ways, which are basically the same thing under the hood" I think isn't ? another way to do the same thing?, since the book even teaches it that way. Ditto basically anything in a "dialectical ratchet".
And I agree that "auto-conversions are a [big] source of bugs in C++ programs" -- they're even mentioned as bad in Aaron's ergonomics post -- but this isn't a coercion. That approach used to be desired, but was found to be problematic before even being proposed as an RFC, and since then the proposals have all had visible markers for "this is happening" (not even might be happening -- ie for an Option it's Some(x), not Option::from(x)).
Well, #2107 and #2120 were both postponed with "the lang team is very interested in pursuing improvements to Result-oriented programming along these lines [...] after the impl period", so it's hard to blame anyone for bringing it up again now.
And I think the fact that different people keep coming up with proposals in the area over the course of multiple years is evidence towards there being a problem worth solving. What's more, every time the proposal has been different. That's not at all "Are the authors just hoping it’ll get through this time?". The "loud opposition" just makes it less likely that someone would be willing to re-open the discussion without feeling strongly, as boats has elaborated before:
What’s really unfortunate is that what this thread demonstrates to me that when an idea is at the “30 minute sketch” stage, if I suspect it will be at all controversial, I can’t post it on this forum or dealing with that thread will be what I am doing all week.
There are plenty of topics that are opened, discussed, rejected, and then never come back up. This doesn't seem to be one of those.
For another thing that came back valuably, see dyn, which, as I posted recently, went over 15 months from one of the most 
'd RFCs in the repo to one with broad support, despite only minor changes in approach.
Javascript apparently calls that an IIFE. It may be worthy of a macro even outside the domain of error-handling, since I've felt sad every time I've typed it.
You're always welcome to make a new proposal. It's probably worth defaulting to a new thread because discourse quickly gets unwieldy as they get long. I'm in favour of having concrete alternatives even when they're to my own proposal.