Hi!
The problem there is that the PHP implementation is likely to code-rot, unless we create really good unit tests that actually run for it.
With service architecture, there should be a test suite running against the service and verifying the compliance with the API definition. So if the PHP implementation passes that, it should be fine.
It would be less bad if the focus were on librarization and daemonization (and improvement) of the existing PHP code so both methods could share a majority of the code base, rather than rewriting things from scratch in an entirely different language.
I think language is secondary here to other concerns. I.e. if the scale requirements require implementing something that is best written in language X, then requiring it to be all in PHP may just not be practical for the scale.
That becomes a hazard when other stuff starts to depend on the non-reduced feature set.
True, but I think there could still be minimal API and extended API. E.g. search engine could support just word match search or advanced expressions, or a database may be transactional with high levels or reliability or non-transactional storage with minimal guarantees. Of course, that means some functions would not be available everywhere - but I don't see a good way to avoid it when the requirements diverge.