I put the override processing afterward to keep it together logically as a
unit. It's certainly more efficient to tie it into the initial list build,
at the cost of mixing the two concerns of building a list, and finding
overrides for items on a list.

I guess if we're happy that the approach of building the list isnt likely to
change, or that if it does it will do so in a manner that remains close
enough the the current, then I'm fine with moving the override check into
addEntry/addEntries. (or rather into a method invoked from both).

The concern would be mainly that if the list building is modified to call a
new 'addXXX' method, that such a change would need to also invoke the
'checkOverride' method.