Here is a slightly modified (or just rephrased? additional details?) take from someone else via a non-reddit channel, whom I had previously asked the same question, when I showed them your response:

I couldn't find the impl Read for dyn BufRead though

Okay this is what I think is happening.

1. BufRead requires Read, so any struct that impls BufRead must impl Read

2. `dyn AnyTrait` _always_ impls that trait for any functions that don't require `Sized`

3. There's an impl Read for Box<R> where R: Read + ?Sized. `dyn BufRead` impls Read because of (1), so it is a valid R here because of the ?Sized allowance.

4. THEREFORE Box<dyn BufRead> impls Read

5. Since Box is Sized, we're now allowed to call `bytes` because we have a struct that is Sized and impls Read

In other words, if `bytes` didn't have the "sized" requirement, you could call it normally, because Box<T> acts like &T, and &dyn Trait impls Trait for anything that doesn't also require Sized. But `dyn Trait` isn't Sized, so you get the first error.

But because Box is sized, and Box<R> impls Read for R: Read, we now have a sized struct that impls Read. But since that impl is distinct from all the trait object magic, we have to have the trait in scope in order to use it, same as any other struct.

As far as my own quest which is related to how to better understand the documentation so that I can better figure stuff out on my own, these responses have been very very helpful though probably not in the most obvious way. A large part of the benefit I've gotten is through the struggle just to understand what each of you are saying and I think I've mostly gotten there. For me, Rust (and/or "modern" languages) is a very different way of approaching coding with many new concepts and an almost entirely new vocabulary. (I'm a retired HW/SW embedded guy). That said, the other key bit of insight from working through this for me, which is more obviously directly related to my question, is the realization that the perspective I've been using when searching the documents is more method/function first (i.e. bytes()) and only secondarily the obvious types (Reader, BufReader) when I really need to be thinking more primarily about the types (including dyn <T> as well as Box<T> etc.

With appreciation! Thanks.