The thing is, you're not proposing any viable alternative to an interface that would have the equivalent functionality. Forcing the body to be a `string` would quickly become a memory problem, forcing it to be a `resource` would force the most basic use cases to create a resource out of a string with some `php://memory` magic, and allowing a `mixed` return type is like opening a can of worms: how do you know how to work with the entity body? What if it's neither a `string` nor a `resource`? Either I've totally misunderstood your point, or this is insane to me!

Re-reading your [original comment](https://github.com/php-fig/fig-standards/pull/244/files#r8742144) makes me think we might not be talking about the same thing:

> Interfaces are for public functionality and enforcing rules about how libraries internally represent something like an entity body [...]

The entity body *is* part of the public interface, hence the `StreamInterface`. We're not discussing internal representation here. This is about how the *consumer* of the library will be able to work with the entity body (display it, dump it to a file, parse it, etc.), not about how the other components of the library will deal with the body (in which case I'd agree with your point).