Untagged frames on R subinterfaces in ROAS design

I was pondering this question from Cisco2 chapter 5:

6. Which statement describes a disadvantage of using router subinterfaces for inter-VLAN routing?

• It is more expensive than using individual router interfaces.
• Routed traffic must contend for bandwidth on a single router interface.
• Trunking cannot be used to connect the router to the switch.
• All untagged traffic is dropped.

Ok, the highlighted answer is obviously correct. But I got stumbled by a possible answer "All untagged traffic is dropped." Now, that actually sounds plausable. If subinterfaces are assigned to VLANs using the encapsulation dot1q VLAN   command, then what, in fact, happens if we have no subinterface for the native vlan? Or if the subineterface does not specift that the vlan is native? Will the packets be dropped?

I have came upon 2 fascinating discussions on this subject:

https://www.experts-exchange.com/questions/28484927/how-a-router-handles-untagged-traffic.html
Craig Beck writes:

When a packet with no VLAN tag enters a switchport it is wrapped in 802.1q. This puts the packet on whichever VLAN is specified as native on that port. While the packet is in the switch it keeps within that VLAN. When the packet leaves the switch via a trunk port the packet maintains its VLAN tag if not on the native VLAN as per the trunk port config. If the packet is on the native VLAN the 802.1q wrapper is stripped and re-applied when the packet enters the receiving switchport.

https://mellowd.co.uk/ccie/?p=2540

This is a description of an experiment the author ran on his routers, and he tried to do different configurations with tagged/untagged traffic on subinterfaces. The cool part of the experiment is using the WireShark info to peek inside the encapsulation process.

I can say that a subinterface is tagged with the native vlan. i.e. no vlan tag:
R1:
interface FastEthernet0/0.20
encapsulation dot1Q 20 native
ip address 20.20.20.1 255.255.255.0
R2:
interface FastEthernet0/0
ip address 20.20.20.2 255.255.255.0 secondary
ip address 192.168.1.2 255.255.255.0
R1#ping 20.20.20.2 repeat 1 Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 20.20.20.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 24/24/24 msOn R1 I created a subinterface with the native vlan. On R2 I added a secondary IP address. Traffic for the 20.20.20.0/24 range goes over the wire without a dot1q tag.

He goes further and checks another possible configuration:

Now let’s get deeper…
R1:
interface FastEthernet0/0.10
encapsulation dot1Q 10 native
ip address 10.10.10.1 255.255.255.0
R2:
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip address 10.10.10.2 255.255.255.0
Here I have R1 configured with a native subinterface, while R2 is configured with a dot1q header of 10. You would expect there would be no communication between them, but you would be incorrect

After checking WireShark and MAC address tables, Darren finds out that

if you have a native subinterface, it will accept both untagged AND tagged frames in the vlan, vlan 10 in my example above. However it will only SEND untagged traffic. Good to know. It can also explain why you sometimes see an ARP entry on one side, while not on the other.

Darren's experiment also provided me with a startling discovery:

You can also mix regular and subiterfaces together on the same interface. 

I have never considered this as a possibility, since the textbook instructs to assign no ip address to the physical router interface before creating subinterfaces. Darren then demonstrates the use such mix on one interface.

R1:
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip address 10.0.0.1 255.255.255.0
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip address 10.0.0.2 255.255.255.0
R1#ping 10.0.0.2 repeat 1 Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 28/28/28 ms
R1#ping 192.168.1.2 repeat 1 Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 24/24/24 ms

This little experiment was a great lesson to me. I will keep this knowledge in mind.