The improvement is to make VPP behave like any other IOS device, i.e. a VLAN 0 tag should be ignored on ingress:

In certain deployments (e.g. with Cisco UCS-B) "Priority Tagging" is used, resulting in frames carrying a "VLAN 0" tag, see e.g. http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/atm/configuration/15-mt/atm-15-mt-book/atm-vlan-prty-tag.html

Standard behavior on devices is to associate Ethernet packets tagged with VLAN 0 with the native VLAN of the interface (i.e. the interface for untagged traffic) - see also the link above and the following quote:

"When a particular VLAN ID is assigned as a native VLAN on an Ethernet interface, frames in the native VLAN transmitted from the Ethernet interface are not tagged. Similarly, any untagged frames received on the Ethernet interface are associated with the native VLAN on that interface. The Ethernet interface can still receive both tagged and untagged frames. The tagged frames are associated with the VLAN ID in the 802.1Q header (see above). Untagged frames do not contain priority bits in the Ethernet frame header and are treated as best effort. On ingress, Ethernet packets tagged with VLAN 0 are associated with the native VLAN of the interface."

The desired target behavior is also inline with the .1Q spec: "The null VLAN ID. Indicates that the tag header contains only priority information; no VLAN identifier is present in the frame."
 
The improvement is to make VPP behave like any other IOS device, i.e. a VLAN 0 tag should be ignored on ingress.

Currently, configuring a tap interface results in VPP dropping packets with vlan 0:

vppctl tap connect tap-admin-vpp
vppctl set int ip addr tap-0 192.168.1.100/24
vppctl set int state tap-0 up

03:20:01:825468: tapcli-rx
tap-0
03:20:01:825472: ethernet-input
IP4: 00:25:b5:00:01:4a -> 01:00:5e:00:00:12 802.1q vlan 0
03:20:01:825473: error-drop
ethernet-input: unknown vlan