There are two EListError, one in Classes and one in fgl which are incompatible to each other. So if something raises a fgl.EListError you can't catch it with a Classes.EListError (which you do if comment the use of the fgl unit).
On top of that, the debugger says in both cases 'raised exception class EListError with message... [Break][Continue]', i.e. no scope/unit qualification, contributing to my confusion.
It was quite annoying. Yesterday, I've chased it about an hour, at some point even started to mistrust the FPC SEH! Accidentally, pressing Alt-Up at the right place, I've found it has a second definition. I couldn't imagine that the reason could be so simple. It is a kind of silent trap.
IMHO the exception in fgl must be renamed. Thus, it will require fgl to be used in units with exception handlers. The problem I see is with the existing sources that catch the current fgl.EListError - they will stop catching in turn.