That said, the things you asked about:
1. I suppose you might get away with linting all of shadow_reuse, shadow_same, and shadow_unrelated. Would that sufficiently disable the feature?
2. The biggest problems with overusing `anyhow` to circumvent the language's error system are performance and type safety. Perf is probably fine enough for most applications (though, we _are_ talking about systems programming, and this is yet another way in which allocation-free Rust is hard to actually do), but not being able to match on the returned error makes appropriately handling errors clunkier than it should be, leading to devs instead bubbling things up the call stack even more than normal or "handling" the error by ignoring any context and using some cudgel like killing connections regardless of what the underlying error was.
3. Rice's Theorem only tangentially related. Your goal, and one that Rust also strives for, is to make it so that changes to the type signature of a function require compatible changes at call sites, which you can often handle syntactically. Rust allows `let _ = foo()` to also silence errors, and where Zig normally allows `_ = foo()` to silence unhandled return values it additionally requires `try`, `catch`, or `return` (or similar control flow). You have options like `_ = foo() catch {}` or `_ = foo() catch @panic("WTF")` if you really do want to silence the error, but you'll never be caught off-guard by an error being added to a function's return type.
You are absolutely right that anyhow doesn't do what you want for a no-alloc situation like a kernel driver or some ESP32 firmware - however it won't compile without an allocator, so, seems like you'd be shifting that problem hard left, the programmer who adds anyhow to their no allocator firmware can't build it.
Yes, I see now what Zig has here is literally a syntax check and so Rice doesn't apply because in Zig the function which returns an error is syntactically different and so Zig can say hey, this is an error function and those are different. I prefer the situation in Rust, but this is an important difference albeit one I don't agree with.
For example you might decide to warn for clippy::shadow_unrelated which says if I have a variable named "goose" and then later in the function I just make another variable that's not obviously derived from the first variable but it is called "goose" anyway, warn me I did that.
2. I don't see any advantage of "largely compatible" error handling over anyhow, maybe you could be more explicit about what you want here or give an example.
3. What you're claiming for Zig here is a semantic check. This could exist but be fallible (it can't be infallible because Rice's Theorem), but I suspect the reality is that it's not a semantic check and you've misattributed your experience since I don't see any such check in Zig. Maybe an example would clarify.