You cant have unicode without the mess of mb_real_uppercase and friends. Concurrency on a webserver? LOL, this is like the lowest bar i have heard. This limit SO much and pretty much forces the concurrency to the client, and thats not always an option.
Of course you can. Write your own abstraction of Unicode string, it is easy. Php has all the tools for it.
Yes, in mainstream PHP you use the webserver to leverage forking. The great thing about that is that vastly simplifies the language and any frameworks written in that language. No, it doesn’t force anything to the client.
Also any performance gains made in web server technology is given to PHP for free.
In Java and Python and the like you typically have a thread pool to handle every request, this has the benefit that you can share memory with mutexes between request (threads) . However 99% of cases that is not typically something you want, to have leaky requests, thus most of the time you write code similar to PHP to avoid any hard to debug lock. In Python you also have bad threading performance because of the GIL, thus you avoid anything that steps into that.
Thus PHP share-nothing-model wins again. It is also a natural fit to stateless REST. In PHP you use the database to share memory (data), which is a natural fit in a web stack. And as with the web server you can now leverage any performance gains in database technology.
Nodejs is of course complete trash with the mini freezes of the event loop. And to leverage multiprocess you have to use something like cluster, thus you are back to share-nothing again.
Thus what you argue for is to change a successful request and memory model because of that 1% use case. That is dumb.
Concurrency support is not needed because that is what the webserver is for.