I'm afraid that this isn't an aviation question, it's more of an IT question and a hard one to answer as the systems involved are proprietary.
I am a software engineer myself, almost 15 years now, half of them in the development of aviation software -yet not safety critical. I will try to address the main question regarding the duplicate marker names.
Uniqueness of waypoints
Waypoints that are expected to be unique within the airspace system under consideration according to
ICAO ANNEX 11 – AIR TRAFFIC SERVICES
APPENDIX 2. PRINCIPLES GOVERNING THE ESTABLISHMENT AND IDENTIFICATION OF SIGNIFICANT POINTS
Paragraph 3:
3. Designators for significant points not marked by the site of a radio navigation aid
3.1 Where a significant point is required at a position not marked by the site of a radio navigation aid, the significant point shall be designated by a unique five-letter pronounceable “name-code”. This name-code designator then serves as the name as well as the coded designator of the significant point.
3.4 The name-code designator assigned to a significant
point shall not be assigned to any other significant point.
There are other paragraphs as well but these 2 are the important ones to know that the point uniqueness is mandated.
You might be wondering then "how did the 2 SIERAs come that close in Bianfable's answer"? If you have a look at the Belgian AIP then you will see that the 2 waypoints have a different parent. The point at northwest belongs to EBST SINT-TRUIDEN / Brustem and the point at southeast belongs to EBLG/ Liège airport.
When a VFR flies within the area of EBLG and they are in contact with the tower and ATC instructs them to "report SIERA" there is no way to confuse it with the "other" SIERA. The "context" is the airport and the waypoints are unique within their context. Finally, please note that these 2 points are VFR; they will never appear in an IFR flight plan like the one in question.
As you can see, while uniqueness can be maintained within the same context, when you "merge" the contexts together like it happens with long distance flights, it's not guaranteed that you will not get any duplicates. As a result, you would expect that a system handling such data would be able to deal with duplicates. Still, it's not black or white.
What could have gone wrong
Unfortunately we can't tell for sure. We are lacking important information like the raw flight plan, the waypoint names and their locations. Also I don't work neither for NATS nor Frequentis that developed the system so I don't have inside information.
I read the report that Dan linked and there are things that need further clarification. Read page 9 and you will see what I mean. One of these points is:
Next, it searches backwards, from the end of that section, to find the UK airspace exit point.
This confuses me. There is no need to search backwards unless you want to compute the 3D trajectory of a descending flight and that can be done in a subsequent state for simplicity. Once you find the first point in the FIR, then you can move forward until you find the first foreign point. Granted, as DeltaLima correctly pointed out in a comment, a flight might exit the FIR and enter back again later on. In any case I would expect the system to not quit after finding the first exit point but make sure that the rest of the points are irrelevant. Can be done in direct or reverse order.
I don't say that I know better than them. But I feel that the wording in the report is (overly?) simplified and that there is certainly more than meets the eye.
On page 6:
The FPRSA-R sub-system exists to convert the data received from IFPS (in a format known as ATS Data Exchange Presentation, ADEXP) into a format that is compatible with the UK National Airspace System (NAS)
But later on
The flight plans delivered to FPRSA-R by IFPS are converted from an ICAO document 4444 (ICAO4444) format to a format known as ADEXP.
Again I'm confused. The first statement implies that FPRSA-R receives plans from IFPS in ADEXP format and and in the second statement in ICAO format. That might seem trivial but things can be lost or taken wrong in translation.
Moreover, according to the same report, IFPS handled the same flight plan without issues so it could not have broken any system; it was tried and it didn't.
Last but not least, we need to have access to the problematic data and as far as I see the flight plan has not been published up until this moment. This is important as according to the same report, the system has processed successfully 15 million flight plans up until now. I find it hard to believe that this was the first time that the system encountered a plan with duplicate points. I might be wrong though as the airlines might be vetting the flight plans, just to be on the safe side. I don't know that for sure.
The most important question that I feel it needs to be answered by the relevant parties (not by anonymous people on the internet) is why a single faulty input resulted in taking out both their main and the backup systems.
We certainly need more information in order to avoid speculation.