EDIFACT normally has (possibly repeating, possibly nesting) segment groups and a lot of code trying to handle EDIFACT skips over that.
At this point, I'm pretty convinced that if you're running into EDI (or its sister formats like HL7) processing issues, its because you've got the wrong data structure in place or you aren't keeping your rules up to date. Once you've got the right architecture in place, you can easily manage 100s of provider/partner-specific rules with one person at 20% time. If you don't your whole company is going to be dealing with data integrity issues forever
A library that I wrote decades ago has some Perl which can do that to produce XML definitions from the UN/EDIFACT published directories. I hope that it can be useful to others: https://github.com/davidcoles/medici
I can speak about ANSI X12 because I've used it (North America), haven't used EDIFACT (non-North America):
Each document type, like a PO or Invoice has a defined structure (by the standards group) which is conceptually nested/hierarchical but physically stored as a combination of tags at the line level combined with delimited elements within a line.
Traditionally the raw data would be pass through a translator tool that converted it into it's hierarchal structure and a person could define a mapping from that structure to their internal systems data structure.
With the internet and XML and JSON, many people/companies weren't aware of the standards and didn't have an EDI translator, so they just winged it and extracted what they needed from the raw data.
There is still a large volume of EDI based data movement and it will probably live for a long time due to cost to change plus having standard document definitions across companies reduces the level of effort to connect many partners to many other partners (it basically reduces the transformations down to a conversation about which things each company does uniquely in the document as opposed to starting from scratch with a completely custom document for every company).