I would recommend future proofing this by raising it to 256 (a hard limit on many areas of the engine) so people don't have to recompile a bunch of plugins in the future.

I would recommend future proofing this by raising it to 256 (a hard limit on many areas of the engine) so people don't have to recompile a bunch of plugins in the future.

I had considered it before accepting this change, but realistically that value is as much subject to change as the 33 was or any other for that matter.

I would disagree with that, there are places where it is not as simple as changing 1 define, the network protocol encoding player count as a byte being one of them. Even if this wasn't the case, I would argue it is a lot more likely for the player counts to be increased somewhere between 100-200 compared to 256.

I think it is worth losing a few kb of memory to save people from having to look through 50+ plugins to recompile.

It not being as simple to change doesn't mean it won't. Even changing the player count to 100 was more than "changing 1 define", and there are rumblings that raising the edict limit may happen as well, which is similarly not quite as simple, and would also result in many plugins needing to be recompiled anyway.

There are no plans to raise it higher on the SourceMod side at this time.

As an aside, your specific example about the engine not raising it higher than 255 is regarding a Steam protocol that has nothing to do with the engine other than some shared history. Multiple other multiplayer games using SteamWorks have also ran into that limit and just relay the count via another method. The GC already sends some pieces of server data to the client. The counts could be added to it as well if it came to that.