It's a fairly simple concept. For the initial console versions of CS1 and CS2, Falcom had to do all the programming work themselves. (I assume same is true with CS3; NISA just delivered the voice samples and script files and Falcom inserted them into the source...and implemented Turbo mode on their end at NISA's request) The way voices usually work in a game like this is that in the game code, lines like these would be used for dialogue lines:
C#:
DisplaySpeechMessage("Rean", charRean, skinSerious, 402, "My name is Rean Schwarzer and I'm here to deliver another anime speech bec... (*pie in the face*)");
DisplaySpeechMessage("Male student", charStudent, null, -1, "Hey! Who stole my pie?")
The numbers in those lines refer to wav-files in the game folder. If it's a -1, there's no voice file expected and the line is always silent, whether a voice file for it exists or not. If 0 or higher, the corresponding voice file is tracked down and, if present in the game folder, played while the text is on-screen. If not present, the game simply ignores it and the line is silent anyway.
As long as the localized voice files have the same numbers as the original files, no work on the programmer's part is needed. You simply replace the Japanese files with the English ones, or put them in a different subfolder and add a single line somewhere else in the code that makes it possible to read from different folders, and you're golden.
The problem comes with the scenario of a publisher coming up with additional voice files. Dropping them in the voice folder doesn't work out of the box because you need references in the code pointing to those files. So if a publisher records 5000 new lines of dialogue, someone has to scour the game code for the right message line and change the -1 to the index number of the new voice file. And do that 5000 times. It's not a difficult job, just a tedious and potentially time-consuming one. For the PS3 and Vita versions of CS1 and CS2, Falcom also had to do their own annual projects, so they couldn't be bothered to take a programmer off their own projects to do that chore. For the PC ports, XSeed had control of the source code so they could let their own programmer fill things in. For the PS4 ports, Falcom already had their development department working on the code, so this was just another to-do item on their list and not something they had to pull programmers off other projects for. (also, Falcom probably realized that their PS4 ports would take a sales hit in the west if they didn't include one of the PC version's biggest selling points)
That's why the initial console versions had the Silent Rean syndrome in a lot of places and the PC and PS4 ports didn't. That's also why people were already expecting CS3 to also suffer from Silent Rean syndrome and CS4 will be the same. If a PC port is developed and NISA decides to go and shoot for XSeed's standards, those missing samples may be recorded (NISA did a lot of re-recording during their attempts to repair Ys VIII's botched script) but they most likely won't be back-patched into the PS4 version.
