The following nodes share the same next index space. Defined in ip/lookup.h

ip4_hop_by_hop_node, ip4_add_hop_by_hop_node, ip4_pop_hop_by_hop_node, ip6_lookup_node, ip4_lookup_node, ip4_lookup_multicast_node, ip4_classify_node, ip6_classify_node

There are a few assumptions here. The IP4 and IP6 next indexes must be consistent.
These nodes use the adj->lookup_next_index to store the next index.

If the next tables per node or per AF aren't consistent, one can expect 'interesting' behaviour.
It turns out that there are already a few features that dynamically register to only some of these nodes, and also register to only one of the AFs.
Resulting in inconsistencies, e.g. a next index of 13 might only be valid if it came through a certain node.

lisp-gpe/lisp_gpe.c: lgm->ip4_lookup_next_lgpe_ip4_lookup = vlib_node_add_next (
mpls-gre/policy_encap.c: vlib_node_add_next (mm->vlib_main,
mpls-gre/policy_encap.c: vlib_node_add_next (mm->vlib_main,
sr/sr.c: vlib_node_add_next (vm, ip6_lookup_node->index, sr_rewrite_node.index);

That said, it would have been very nice if we could properly support this functionality.
I found this while trying to make the 6RD function a plugin, where I require to add a 6RD encap next to the adj->lookup_next_index for a particular FIB entry.
If we supported it correctly, we didn't need "dummy" nodes for features supported in one AF but not in the other (e.g. IPv4 Hop-by-hop).