I think this can be done in the Makefile if not already done tbh

@ostrolucky most of those comments are intentional of course.

• There is no assumption about the location of the composer.json. It is used if you have a "normal" install. Otherwise we can find nor use it.
• The use case for the script is being able to fix the cache part of broken installs. No external dependencies, so no AppKernel loading as it depends on stuff in the cache and/or autoloader. If you have a "normal" install, it works. If you don't, it won't. But the same goes for bin/console and we keep that in there in the default install. If your environment is too broken to use this script you're stuck with using shell-fu anyway.
• The use of system commands is intentional, as it provides much more reasonable output than recursive unlink will ever give (think read-only filesystems etc.). Admittedly that output is currently not being piped correctly, and you're right about the exit codes.
• The path and newline separators do not matter. PHP is well documented since somewhere in the 4.x era to be agnostic to them. Using DIRECTORY_SEPARATOR in paths and PHP_EOL in console output has no added value therefore, they're only useful for example in parsing local paths and writing platform-specific file formats.
• The bin/console script is just as (un)testable.

Adding such script just for one uncommon use-case is a total mess. There are workarounds for symfony/symfony#23592, and implementing this kind of logic rough and tough like that just lacks understanding of how Symfony works... 😕

The workaround appears to be rm -rf according to symfony/symfony#23592 (comment). I know it's rough and tough, but it's a PR in Symfony Standard Edition, not Symfony core. It doesn't matter that you can break it by going power-user in Symfony, as that will break more scripts, including potentially bin/console itself.

Anyway, if the discussion is going to the level of implying I don't understand how Symfony works I'll just close and we'll keep advising people to rm -rf.