I'm ambivalent about this. On the first hand the NC has much better information on the node's neighbors on the other we take out user control over forwarding with this...

Well, first of all, the current behavior is broken. (A node with more than one interfaces may have a route in its FIB that matches the destination, e.g., the default route which may return another interface than the one stored in the NC, resulting in not sending the packet.)
Second, the user may still pass a interface to the function which doesn't get overwritten.
Finally, we may swap the order of the gnrc_ipv6_nc_get() calls, but I would prefer to first lookup in the neighbor cache and then consult the FIB over the reverse order.

@emmanuelsearch, @cgundogan, @Yonezawa-T2, any opinon?

The current implementation already prefers NC over FIB, except interface.

The outline of the current gnrc_sixlowpan_nd_next_hop_l2addr is as follows:

1. Lookup FIB to next hop and its interface.
2. Lookup NC with the destination address and the interface of the next hop (if any).
3. If NC contains the destination address on the interface of the next hop, send the packet to it directly.
4. Otherwise, forward the packet to the next hop.

This patch changes step 2 and 3 to follows:

2 . Lookup NC with the destination address and the original interface.
3 . If NC contains the destination address on the original interface, send the packet to it directly.

and add the following between 3 and 4:

3.1. Lookup NC with the destination address and the interface of the next hop (if any).
3.2. If NC contains the destination address on the interface of the next hop, send the packet to it directly.

I agree with @OlegHahm, looking up NC with the destination address and the interface of the next hop seems make no sense.

@Yonezawa-T2, thanks for the clarification.

So, can we finally merge this?

I'm not sure how to test this, but at least networking through a border router works for both master and this PR. (Untested) ACK.

Tested, @kaspar030 confirmed. Go.