As far as I understand the problem, this applies to any what I would
call "combined fields" like ip.addr being a combination of source and
(or) destination address.
It applies to any field that can appear more than once in a packet.
"combined fields" are one example, as they appear in the packet as
copies of more than one existing field, but there can be other types of
fields that can appear more than once - for example, even "ip.src" or
"ip.dst" can appear more than once if the traffic involves tunneling of
a packet layer that includes IPv4 inside a protocol stack that includes
IPv4, and some protocols might have multiple instances of a given field
even if you aren't doing tunneling.
Oh, and it could also appear in many (all?) fields for a protocol
carried over TCP or carried over a protocol carried over TCP or
(...transitive closure), because you can have more than one packet for
such a protocol inside a link-layer frame if they'll fit.
The only fields it doesn't apply to are those that can never ever
appear more than once in a given packet - and one should never
underestimate the ingenuity of networking engineers in figuring out new
ways of doing tunneling, so one should never underestimate the
likelihood that you'll see more than one instance of a field for a
protocol that you can't imagine appearing more than once in a packet.
(I suspect there is at least one capture out there with more than one
eth.type field in at least one packet).
So the question is whether we should give this warning for all fields
that are "combined" fields", those fields plus all fields that could
show up in a tunneled protocol or any protocol that can be carried by a
tunneled protocol, all those fields plus fields that could appear more
than once in a packet, or just for all fields.