The example given is a bit mood as @ didn't support stream resources as well.

However most stream resources do have a file-path already, so this can be wrapped - for example:

/**
 * Class CURLResource
 *
 * CURLFile of a stream resource
 */
class CURLResource extends CURLFile
{
    public function __construct(
        $resource,
        string $mimetype = null,
        string $postname = null)
    {
        if (!(is_resource($resource) && 'stream' === get_resource_type($resource))) {
            throw new InvalidArgumentException('Not a stream resource');
        }
        if (null === $filename = stream_get_meta_data($resource)['uri'] ?? null) {
            throw new InvalidArgumentException('Incompatible stream resource, "uri" metadata missing');
        }
        parent::__construct($filename, $mimetype, $postname);
    }
}

Externalized it is just:

new CURLFile(stream_get_meta_data($resource)['uri']);

This might already suffice for your example. If the resource closed automatically (e.g. one from tmpfile()), the resource handle has to be kept until the file has been send.

You can also post directly from a stream with curl, just not AFAIK for post form data encoded file uploads, but for the whole request body, see CURLOPT_INFILE,

For more options, just properly wrap . It should bring the (imagined) headaches to a minimum.

But with all the issues of hidden state a stream resource can come with, I wonder if it is really useful to have support for that in the extension itself. Handling of temporary files is much more straight forward, I wonder bit what the headaches are. Just my 2 cents.

I'd rather prefer CURLFile accepting resource handle directly.
Would save a lot of headache, including the issues of UNICODE names under Windows.