This is overall a very good list. There are probably just these two things which I actively disagree with.

1. Using the #[non_exhaustive] attribute on every public enum seems like poor advice. Surely you want the caller to get an error when a new variant is added so they can deal with the new logic, rather than having that new stuff go into the fallback arm you had to write?
2. Listing “code size” as the only exception to using dyn over a generic or impl is probably correct but maybe a bit misleading. Not needing to specify generics up a big chain of types isn’t just difference in text length, it also requires less monomorphisation. The way it’s written now, it sounds like if Google made the Rust standard library, std::fmt::Formatter would have a generic to hold the formatting thing, in addition to its lifetime.

score 1 · canonical

Is this only a problem if you have partial compilation/a shared library? Because, sure, at the call site you could assume that String: Magic is true, but as soon as that impl gets typechecked, that gets rejected, and thus, your program will too. So surely the bad example under heading The catch: how do we decide the impl is invalid can’t occur?

score 1 · canonical

I fell so nostalgic for themes like this, having grown up on Windows XP. That and the Windows 7 Aero aesthetics are themes I wish would exist more of today.

score 1 · canonical

I’m very excited to see improvements to the size of the target directory coming! That grows to 50 GiB within a few compilations of work on a real program I work on at my job and it’s annoying having to run cargo clean so often.

score 2 · canonical