1. expanding the matrix to run prefer-lowest in every case
   By including this in the CI, we can ensure that the lowest required version of the composer packages are supported as claimed in composer.json. This feels important for maintaining the integrity of the package, especially since it supports a wide range of PHP versions. If a unit test fails with older dependency versions, it gives us the opportunity to determine if we need to increase the lowest allowed version of a package, drop support for a particular php version, or find a workaround to resolve the issue. By running this test on CI, you can catch and address any issues that may arise, ensuring that the package remains compatible for all users.
   That's why I also had to upgrade the lowest allowed versions of phpunit, they were not compatible. Fortunately this was only a dev requirement.

2. adding all those extensions to the PHP build
   I originally included this to specify which extensions are required for the package (still have to remove what's not needed). But I can see why you don't need this, so I will remove it. By the way, most of the required extensions are already loaded by default: https://github.com/shivammathur/setup-php/wiki/Php-extensions-loaded-on-ubuntu-20.04

3. adding the plugin to composer.json (why?)
   It's an approved security layer and added by composer itself. Perhaps you are running a version lower than 2.2.0 ? https://getcomposer.org/doc/06-config.md#allow-plugins

4. running the CI on feature branches
   This makes it possible for contributors to have feedback while developing a feature for this repo. I think at the moment you only receive feedback when you open a PR? It feels better to only open a PR when you know the feature is stable and it avoids the need to fix issues after the PR has been opened.

1. expanding the matrix to run prefer-lowest in every case
   This is a difference in philosophy. I feel that running prefer-lowest for the minimum version of PHP and maximum is sufficient.

2. adding all those extensions to the PHP build
   Thank you!

3. adding the plugin to composer.json (why?)
   My question is more that I don't know what dealerdirect/phpcodesniffer-composer-installer is, or why we need it.

4. running the CI on feature branches
   I believe the reason you want this change is so that when contributors fork this repo and push to a feature branch on their own fork, their changes will execute a workflow run in their own fork. The problem is, if we made this change in our repo, every PR or push to a feature branch results in two workflow runs - once for the branch, and once for the PR. In the past we have found this duplication of workflow executions confusing, inefficient, and unnecessary, and that is why we have restricted workflow runs to only the main branch and PRs. To execute a workflow on a fork, you can either submit a PR to the main branch of the fork, or change the file as you have here in the fork. Additionally you can submit a PR here and we will run it. We could also add workflow_dispatch to the action, so contributors can manually run the actions on their forks.

1. Updated
2. Updated
3. Removed it, but this will pop up again next time composer is run. It's coming from a dev dependency: phpcompatibility/php-compatibility
4. Updated

These items will be addressed in #2431