Accepted, declined, discussion drama. That is how most posts about PHP 8.6 RFCs read, and the vote cycle is in full swing this month. I read RFCs for a different reason. Not “what do I get”, but “what will my current code look like next year”.
One RFC is a feature. Ten RFCs are a direction. When several push the same way, toward stricter types, explicit declarations, deprecating some old freedom, the direction tells you which of your habits are becoming legacy while you still type them. Syntax sugar is the least interesting part. Deprecations are the most interesting, because every deprecation is a migration with a countdown attached.
So for each accepted change I ask an existing codebase three things. Does our code do the thing that is becoming discouraged, and how much of it. Can we move toward the new way today, on the current version, without waiting for the release. And do the tools understand the change yet, static analysis and the framework, because adopting syntax your analyzer cannot parse means turning the analyzer off. Bad trade for sugar.
The answers split into two piles. Prepare now: stop writing the deprecated pattern in new code. This costs nothing and shrinks the future migration every day. Leave alone: anything that requires touching stable production code before the version exists. RFCs get rejected. Details change until GA. Preparing direction is cheap. Preparing specifics is gambling.
A year from now half of these RFCs will be forgotten and one of them will be the reason some project cannot upgrade. I have been that project. Reading them in August is how I make sure it is not this one.