Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

V2.8.0 upgraded rmccue/requests to the (breaking) v2.0. However, since 2.8.0 is semantically nonbreaking, any other PHP deps using the older version rmmccue/requests alongside wp-cli v2.x are now broken.

The easiest replication case is simply installing "wp-cli": ">2.7.0" as a dev dependency on a Composer-based WordPress install < 6.2 , and you should get a WSOD (since it installs wp-cli@2.8.0 and therefore requests@2.0 to the same namespace used by WP).

To illustrate the breadth of the issue effect on the ecosystem, installing wp-cli-bundle at a fixed 2.7.1 will cause the same issue (since wp-cli@2.8.0 is meets the SemVer requirements). This holds true if you use tooling like wpbrowser,phpstan-wordpress, or something that relies on 'wordpress-stubs' since they all currently use Requests 1.x internally., but install the latest semantically-compliant version of wp-cli).

(If you have a local plugin or theme, just delete and reinstall your composer deps from your existing lock file, and you'll see those scripts will throw fatal errors).

Temporary workaround is to explicitly set wp-cli to v2.7.x` as a local dependency, so any packages that are expecting a SemVer compatible release get locked to the lower version).

Describe how other contributors can replicate this bug

1. Create a new WordPress install with composer. Set the WordPress Version to <6.2, and wp-cli-bundle to 2.7.x.
   E.g.

{
  "name": "example/wordpress",
  "type": "project",
  "extra": {
    "wordpress-install-dir": "wp",
    "installer-paths": {
      "content/plugins/{$name}/": [
        "type:wordpress-plugin"
      ],
      "content/themes/{$name}/": [
        "type:wordpress-theme"
      ]
    }
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    }
  ],
  "require": {
    "johnpbloch/wordpress": "6.1"
  },
  "require-dev": {
    "wp-cli/wp-cli-bundle": "~2.7.1"
  }
}

2. Confirm that wp-cli/wp-cli v2.8.0 was installed (and not 2.7.x), and that rmccue/requests is at v2.x (and not v1.8.x)
3. Visit the WP admin, and see a WSOD with a similar PHP error due to requests 2.0 being included in the autoloader,.

PHP Fatal error:  Uncaught TypeError: Argument 1 passed to WP_HTTP_Requests_Response::__construct() must be an instance of Requests_Response, instance of WpOrg\Requests\Response given, called in /path/to/wordpress/wp-includes/class-wp-http.php on line 397 and defined in /path/to/wordpress/wp-includes/class-wp-http-requests-response.php:42

Note: wp-cli-bundle is used as a proxy for any composer dependency that doesnt have wp-cli set to a fixed version before 6.1

Describe what you expect as the correct outcome
It seems to me a couple things are going wrong here:

1. wp-cli 2.8.0 should probably not be throwing an error when used on WordPress < 6.2, even if thats WP install is using Composer. I don't think thats really doable without resorting to something equally breaking like namespacing dependencies, which brings me to:
2. wp-cli 2.8.0 (and therefore rmccue/requests) should not be an acceptable Composer version on projects that rely on rmccue/requests@1.x.

Let us know what environment you are running this on

PHP 8.0.26 (wsl2 + devilbox + ubuntu 20.04). Im filling this at 3AM from my mobile device so ill fill this in later.

Provide a possible solution

TBH I think the real solution is to re-release v2.8.0 as v3.0.0, but I doubt thats gonna fly. Barring that however, all projects that depend on wp-cli (including wp-cli-bundle) will need to lock themselves to wp-cli 2.7.x or upgrade their usage of rmccue/requests to v2.x (which to be clear means that v2.8.0 will no longer be compatible with Composer-based WordPress < 6.2)

Provide additional context/screenshots

As mentioned, im AFK, but here's a real world example affecting Codeception tests in wpgraphql-acf.