I’d really like to get a second opinion on this one.

I would personally remove that class:

• It's not used internally in Timber
• It doesn't really provide any features
• It's (very) incomplete: it's missing cookies, files, headers, etc.
• It's not following any standard (PSR-7)
• There's plenty of maintained/well tested libraries that provides a Request object (https://github.com/laminas/laminas-diactoros, https://github.com/Nyholm/psr7, https://github.com/guzzle/psr7, etc.)

IMHO, 2.0 would be a good occasion to get rid of it :) Further more, as long as the class isn't used inside Timber, I don't see any valid argument to keep it, especially now we're composer only. If a user wants a request object, let's add a quick how to in the docs:

// composer require nyholm/psr7-server

add_filter('timber/context', function($context) {
    $psr17Factory = new \Nyholm\Psr7\Factory\Psr17Factory();

    $creator = new \Nyholm\Psr7Server\ServerRequestCreator(
        $psr17Factory, // ServerRequestFactory
        $psr17Factory, // UriFactory
        $psr17Factory, // UploadedFileFactory
        $psr17Factory  // StreamFactory
    );

    $context['request'] = $creator->fromGlobals();

    return $context;
});

☝️Now you have a really complete ServerRequest object to play with. And the Timber Team doesn't have to worry about this class anymore.

Now, if we have to keep it, I'll all for leaving CoreInterface out of it but as you said, it's so thin we would have to enhance it which would increase the code base to maintain.

@nlemoine I’m all for removing this 👍. Thank you for providing a different solution using one of the PSR-7 libraries. I added a PR in #2683.