If you want to investigate the theory behind asymmetric VLANs I'd like you to refer to
RFC5517. Though this RFC describes "Private VLANs" (PVLANs) configurabe with Cisco's switches you can adopt the basic ideas depicted there and apply them to D-LINK's asymmetric VLANs by translating a PVLAN's "primary VLAN" to D-LINK's "shared VLAN" and any PVLAN's "secondary community VLAN" to a D-LINK's group VLAN used to configure access port groups. However, the PVLAN's concept of a "secondary isolated PVLAN" is not portable to a D-LINK switch. Using a D-LINK switch you only can simulate the concept of an isolated PVLAN by configuring access port groups containing a single device only. But that costs a lot of VLANs (one per isolated device plus the shared VLAN) which is in contrast to a real isolated PLVAN that only needs two VLAN-IDs (the primary plus the isolated secondary VLAN-ID) and some switch-intrinsic logic that isn't implemented with D-LINK switches.
The RFC also covers switch interconnections where the linked ports are the only ones per switch that have to be configured as trunk ports for all VLANs, that make up the asymmetric VLAN domain, that is the shared (primary) VLAN and all its associated group (secondary community) VLANs, while the special rules for a secondary isolated VLAN don't have to be considered if you don't use it in order to be compatible with switches that don't implement Cisco's PLVAN concept. In addition, because they are unaware of the special semantics of the asymmetric VLANs, using VLAN trunk links is a vendor independent method to connect switch domains of different vendors that may have different ways to implement and configure asymmetric VLANs. For example, if you don't want to use an isolated PVLAN but only community VLANs you can connect a Cisco PVLAN switch domain to a D-LINK asymmetric VLAN switch domain via a VLAN trunk link between an (edge) Cisco switch and an (edge) D-LINK switch.
The basic idea with D-LINK's implementation of asymmetric VLANs is to configure any group access port or shared port as a standard access port for the group or shared VLAN (that is also PVID is set to group or shared VLAN), respectively. In addition any shared port is also configured as untagged member of any group VLAN and any group port is also configured as untagged member of the shared VLAN. In contrast, in a Cisco switch domain you would go a completely different way to configure the same using the PVLAN semantics (leaving aside isolated secondary VLANs for interoperability). And TP-LINK, HP and SMC may all have different command sets and vendor specific implementations for asymmetric VLANs or PVLANs (if they implement it at all!) which makes it difficult, complicated and possibly error-pro-ne due to side effects of vendor specific solutions that are hard to discover. And as is always the case with interoperability: in case of problems any vendor you ask for help will point you to the other one ...
That's why I wouldn't use asymmetic VLANs with switches from different vendors. Using standard VLANs you'll take a much lower risk to run into interoperability problems when using switches from different manufacturers. Using standard VLANs the isolation of device groups shifts from Layer 2 to Layer 3 of the network stack, that is from Ethernet to the IP layer. That's why you have to use a firewall (and IP routing) between different VLANs in order to establish rules that govern what kind of traffic is allowed or disallowed to flow between VLANs. Of course this is more costly because of the additional firewall needed. But from the operational point of view such a standard setup is more flexible and reliable than an (unusual) asymmetric VLAN setup across switches from different vendors.
