I finally figured this out after working with physical switches, some trial and error, and further reading.
This can be a very confusing because a "trunk" can mean different things with different vendors. It basically means a port that is "tagged" with 2 or more VLAN IDs, or with some vendors all VLAN IDs. With a vSwitch a "trunk" port is "All (4096)" which means all VLAN IDs.
With VLANs there are "tagged" and "untagged" VLANs. A tagged VLAN adds extra information to the ethernet frame to indicate which VLAN a message belongs to. An untagged VLAN doesn't add this information, and strips VLAN tag information matching its VLAN ID. A "tagged" VLAN is useful for expanding a VLAN across more than one switch (physical or virtual).
On a physical switch a switch port can only be attached to one untagged VLAN, but can be "tagged" with multiple "tagged" VLANs. A switch port is always associated with at least one untagged VLAN, with some vendors VLAN 1. The tagged VLANs take precedence. Devices plugged into a switch port with a tagged VLAN must understand what a tagged VLAN is and attach the correct VLAN id. If the recipient is plugged into an untagged VLAN of the same ID, this information is stripped before it receives it, so it doesn't have to understand what a VLAN is.
With a nested ESXi environment, the master ESXi host acts as your physical switch. If you tag a port group on a nested ESXi host with, for example VLAN 100, the master ESXi host won't know what to do with the VLAN tag information. Because of this the master ESXi host needs to be on VLAN 100 OR (for other VLAN's to work) "All (4096)".
In a real environment you may not want to trunk all VLAN IDs on an uplink. If you have a vSwitch that has port groups with multiple VLAN IDs, you have to at least tag these uplink ports with those VLAN IDs in order for a VM to communicate with another VM on another physical host. Otherwise only VM's on the same physical host will be able to communicate.
The vSwitch really hides a lot of stuff you'd see on a physical switch.