Idea: ifdef-like feature to ease userland BC

This breaks if you use new syntax features like the array shortcut
$var=[];, traits or similar.

Right, but those aren't problems. I can't see anyone willingly writing:

#ifdef PHP_5_4
$a = [1,2,3];
#else
$a = array(1,2,3);
#endif

They will simply write:

$a = array(1,2,3);

For traits, again, it's unlikely people will want to write two sets of code and deliberately duplicate things. They'll simply just not use traits.

The only case where what you're saying makes sense is where features are removed in favour of alternatives, and I can't see that happening for any syntactic features.

--
Andrea Faulds
http://ajf.me/

I'm not necessarily in favour of this idea as a core feature but to
give a more practical example of how this could be useful: generators
can give considerable efficiency gains where previously more resources
would have been consumed by a process yielding values over time.
Before 5.5, generator code would cause a parse error.

Imagine the following somewhat contrived example:

function some_func() {
$fp = fopen('some_file.ext');
$result = array();
while (false !== $line = fgets($fp)) {
$result[] = $line;
}
return $result;
}

foreach (some_func() as $foo) {
// do stuff
}

Imagine that some_func() is only ever used in the context of a
foreach. For BC reasons, we have to keep this API. Since 5.5, we could
use a generator (yes, we could use an iterator, I said it was
contrived :-P), but we need to provide BC with older PHP versions:

function some_func() {
$fp = fopen('some_file.ext');
#if PHP_VERSION >= 5.5.0
while (false !== $line = fgets($fp)) {
yield $line;
}
#else
$result = array();
while (false !== $line = fgets($fp)) {
$result[] = $line;
}
return $result;
#endif
}

As another example, imagine a heavy data processing routine that uses
goto for performance reasons, but before 5.3 would fall back to using
private methods instead:

#if PHP_VERSION >= 5.3.0
private function partOfRoutine()
#else
partOfRoutine:
#endif
{
/* stuff */

#if PHP_VERSION >= 5.3.0
anotherPartOfRoutine();
#else
goto anotherPartOfRoutine;
#endif
}

Another advantage for performance-minded people is that a
pre-processor is a one-shot deal, whereas runtime checks are
potentially performed a few hundred times a second with the exact same
result every time for ever more.

However the thought occurs that, while potentially useful, a
pre-processor of this nature could easily be done with a userland
implementation, a composer dependency and a composer
after-install/after-update script...

Thanks, Chris