Rollback PHP 7.3 requirement and freeze the state at 1.x

That's because the object type became available since PHP 7.2 (https://wiki.php.net/rfc/object-typehint). Drupal docs (https://www.drupal.org/docs/system-requirements/php-requirements) say the 7.1 is not recommended so I'd classify this issue as Bump PHP version in cshs.info.yml to 7.3.

If you're willing to continue using the module with PHP 7.1, I'd suggest finding all object $ and replacing them with \stdClass $ (2 occurrences for now) however the future versions of the module may/will receive more incompatible changes with PHP 7.1 so better option is to upgrade your PHP to 7.4.

Here is the patch for those who need PHP 7.1 support.

Would it be too much trouble to create a new major version of this module? Updating to php 7.3 is a BC-breaking change and instead of having to reverse-patch every single new release could we just leave a version of CSHS static that supports php 7.1? I'm also in a situation where my hosting provider is locked to 7.2

I see no difference between a version that will not receive updates and a situation where the patch to support PHP 7.1 should be applied. Actually, as long as the patch is applicable, you get the latest codebase adopted to PHP < 7.3.

Here is the updated one for the latest module version.

The problem is that this major version will continue to receive updates that will then require future patches. I've got my composer.json file pinning this module at "1.5" now so we don't have to worry about it being updated in the future. Sites using this module on PHP < 7.3 should NOT update to this, and doing so WILL break their sites. That's cause enough for a new major version.

Additionally, shouldn't this module's composer.json add php 7.3 as a dependency now?

Additionally, shouldn't this module's composer.json add php 7.3 as a dependency now?

Probably it should.

The problem is that this major version will continue to receive updates that will then require future patches.

Ideally not, but most probably yes. That's the trade-off the one should accept sticking to the legacy software. Again, what is the purpose of freezing a codebase at the specific version that will never be updated? As you said, you can hardcode the version to which the latest patch from this issue is applicable and that will have the same effect.

The purpose isn't to freeze a codebase, it's to split the new development into a new branch (8.x-2.x) so that you don't have to consistently re-patch your updates. Developers expect updates in the same major version to not break things. Since you're changing dependencies from php 7.1 to php 7.3 (which may not be an easy update or may not even be possible depending on other external factors) I would expect the module to create a new major version.

As it is now, there's no warning to developers that even though they might be using a version of PHP that's still supported (though not recommended) by core 8.x, this module will start to throw errors. A new major version branch where development moves to creates that clear line of demarcation

Got the point. Makes sense.