Ok.
With all the respect to feelings, it is technically known to be the bad idea.
There's no way to force stubby to listen on some tcp ip
ort unless you move dnsmasq from there.
Same is true for lan, loopback addresses, no matter the family (v4/v6).
starting stubby with ::1@53 when dnsmasq is already running:
stubby can't listen on TCP [::1]:53, because port is busy by dnsmasq.
althrough stubby doesn't complain to listen on UDP [::1]:53, but it will work as poor-man per-cpu load-balancing - part of queries to [::1]:53 will go to stubby, other part - to dnsmasq. if dnsmasq has [::1]:53 upstream, half of possible dnsmasq's queries will be looped back into it.
starting dnsmasq when stubby is already running with ::1@53:
dnsmasq can't listen on TCP [::1]:53, because port is busy by stubby.
althrough dnsmasq doesn't complain to listen on UDP [::1]:53, it will work as poor-man per-cpu load-balancing - part of queries to [::1]:53 will go to stubby, other part - to dnsmasq. if dnsmasq has [::1]:53 upstream, half of possible dnsmasq's queries will be looped back into it.
more tech details about binding here
https://linux.die.net/man/2/bind
solution is to bind stubby and dnsmasq to ::1 (since it's the only ipv6 loopback address, google for ipv6 address types) and to different ports.
for example, stubby - to [::1]:5353, it will be valid config.
okay, but what is the need for that if [::1]:5353 will never be used by anything locally (on router) except dnsmasq which is already configured to reach stubby via 127.0.1.1:53?
the only correct answer - there's no need, except waste of ressources (own time, sockets, cpu power) and curiosity.