Right after the section you quote, I do show in my proposal how I think proc-macro lints could ask for type information. I could definitely implement my
sqlx_lints::uncommitted_transaction lint with that. Sure, it might get tripped up in more complex cases but we're just talking a simple lint to catch a typical beginner's mistake. It's not the end of the world if it doesn't catch everything.
I can also easily conceive of a way to query the compiler for a
TokenStream of the definition of a type/trait/impl/function for more complex lints.
Is it perfect? No, I'll gladly admit that. The important thing is that there is a very clear path to stabilization vs developing a whole new API for interfacing with the compiler. This proposal can act as a stopgap solution or a fallback, because any hypothetical API effort can easily fall to excessive bikeshedding, or conflicting requirements, or the feature shepherd just plain losing interest or not having time to finish it. Stabilization with that large of an API surface is also going to be a whole ordeal in itself.
My proposal I will gladly start implementing right now, and I figure I could have an MVP in maybe a month. I almost didn't even bother with writing a proposal first but I figured the PR would get rejected without an RFC. It seems the main benefit of posting this proposal wasn't to actually workshop the feature anyway, but to learn about concurrent efforts and existing workarounds, so I guess it's already served its purpose.
IIRC proc macros themselves were purely meant as a stopgap. They're certainly flawed and limited. However, their replacement has yet to materialize, and I certainly think we're better off having them than if we had decided not to implement them and to wait for a more optimal solution. It's the same thing here. I don't want to be sitting here three years down the road still thinking, "man, I really wish I could implement my own lints."