It should be noted that unlike most functions, FibEntry_GetNexthops() does not return a copy, but a pointer to the FIB entry content directly.

As such, we need to always work on a copy when manipulating the list of next hops.

MAP-Me code was wrongly considering this list to be a copy, thus iterating and removing entries in the same NumberSet. The consequence was that not all entries were removed, which was only visible when getting out of multihoming conditions, when the remaining next hops were unwanted (eg ~50% chance in case of WiFi/Cellular multihoming).

One of the visible consequence was that interests were still sent to some interfaces even after a MAP-Me event (such after after setting interface priority), thereby causing traffic to be sent on the client interface (for data packets).