If it was literally just running Clippy, then I wouldn't like that, because there are Clippy lints that are purely about idiomatic style, or approximate checks that may have false positives, so it would make a worse signal/noise ratio of the compiler warnings.
The way I understand it is that rustc warnings are about serious issues and warnings that are problems with high probability. Warnings about issues that are too subjective or too imprecise are delegated to Clippy.
In this case misused read()/write() call is not merely non-idiomatic code, but most certainly a bug, so it could be graduated from being a lint to a warning.
There also seems to be a small parallel with the recent #[must_bind] thread. In that thread, it was observed that not binding a guard is often wrong in subtle ways (and #[must_use] doesn't really help). In this thread, the #[must_use] on the return from Read::read() also doesn't really help, because it's often wrong to ignore the usize within the Ok variant.
I'm pretty sure naming comes from libc's read/write so I don't really see problem there.
Unless you're concerned about lazy users who doesn't read docs I do not see anything poor with this naming.
Renaming methods just for the sake of it is pretty much pointless effort.
io traits should provide comprehensive documentation for user to understand each part of interface
To be completely fair to the users here: many uses of the Read/Write traits are done from concrete types, which on their documentation page just show that they implement Read::read/Write::write without any documentation. (Because the documentation is provided only on the trait page and not the concrete type's page.)
I agree that it would be quite beneficial for any "root" Read/Write type to provide specific documentation on these methods for whether and when they can provide partial reads/writes. I don't think a method rename is needed (or really all that desirable) here, and this can be handled by targeted docs on the impls.
In my case it's not laziness or not reading the docs. I'm fully aware of these methods and the pitfall, and yet from time to time I forget and make this mistake, because nice and simple read/write names sound like what I want to do. They sound correct. They don't stand out in the code as doing something else than "simply" read/write.
I've mentioned earlier that I suspect it's a homage to libc::read/write, but I've never used them. For networking I always try to use anything higher-level (exactly because there are so many sharp edges), and for files there's fread/fwrite (not fread_exact/fwrite_all).
I wanted to say that other languages don't have that footgun, but Python actually does. It even has examples in the documentation that don't check if the data was written! OTOH in Node.js write() always writes everything.