@BenMorel First let me say that I believe making normative statements about return values in interfaces is extremely problematic in PHP because you're creating unenforceable constraints. A law that can't be enforced is a bad law. IMO it's pointless to ever say anything but  `MAY` and `SHOULD` with regard to return typing in PHP. Dynamic return typing allows for real flexibility and legislating this away is an "enterprisey" mistake IMO.

Beyond this, requiring support for a userland type instantly imposes performance penalties. I don't expect people to be sympathetic to this issue because everyone else seems to be approaching this PSR from the standpoint of HTTP clients where you don't have to worry about handling tens of thousands of `Request/Response` objects simultaneously inside a single process.

However, my concern is servers. I spend most of my real work time using a closed-source standalone http and websocket server that's much faster than the PHP web sapi and as performant as node.js. It holds open tens of thousands of simultaneous client connections per machine at any given time. Abstractions are nice, but this level of performance would be impossible if everything had to match up with a userland interface specification internally. To achieve real performance internal implementation details must avoid deviating from native types whenever possible.

I get it: frameworks aren't concerned about maximizing performance and PSR is a "framework thing." But if userland constraints are enforced on internal `Message` implementation details I'll just have to ignore the standard.

> How do you know how to work with the entity body that's returned by the Request or Response then, if it's not a well-known interface?

To actually answer your question ... isn't it obvious? How difficult is this:

```php
<?php
$body = $message->getBody();
$body = ($body instanceof Streamable) ? $body : new Stream($body);
// Assume Stream::__construct() throws if $body isn't a string or seekable resource or whatever
```

Enforcing a typehinted return instantly imposes a performance penalty. As far as I'm concerned this is just another implementation detail that cannot be standardized without a negative effect. Return values are not part of interfaces in PHP no matter what your docblocks and IDEs tell you.