usually ports on the L2 switches can be configured in the following modes: access, hybrid or trunk (I think, terminology may vary among the different vendors). The IEEE 802.1q standard actually mentiones about these three modes somewhere in appendix, so I think this is not really a mandatory part which every switch must follow?
Furthemore, are these modes purely software concepts or they can, and usually are, implemented on a real hardware?
The standard has nothing about Hybrid. It specs 'untagged' vs. 'tagged', and has some language about trunks. Annex E.3 talks about "Heterogeneous networks: Intermixing IEEE 802.1D (D) and IEEE 802.1Q (Q) Bridges", in which cases bridges conforming to .1Q can be intermixed with .1D bridges.
When reading standards, make sure you understand the formal language used by them. Can/May does not mean Must, which is a much stronger word.
The standard just states that a properly compliant .1q device should be able to talk alongside one that isn't vlan tagging aware.
That said, what is popularly termed 'Hybrid' by some vendors works just fine, but doesn't mean all vendors have to present such a model. In general, most people don't find it all that interesting to configure.
The lines of software and hardware are blending together pretty quickly. While something like a large enterprise switch be "hardware". Something like a VMWare ESX cluster would do all VLAN tagging in software. Or a firewall, or a server, or a software based router. (ie. Cisco 7200) all tag vlans in software.
Even most of the "hardware" now is written in software and can be re-programmed on the fly. (ie. typically downloading code during boot). So what makes hardware any different than software?
Actually it does in 802.1Q-1998 edition, in Annex D. It's been removed from the further revisions of the standard,
What I was meaning is should the h/w implement, for ex., registers where one can set such attributes of a port, as access, trunk, hybrid, or these concepts (access, trunk, hybrid) are purely related to vlan and thus just reflect the way vlan operates on a particular port(s) ?
A lot of controlpath software support such switchport modes, and obviously somehow they rely on the way the underlying hardware implements these modes.
I'd imagine that switches that use hardware chips would probably be programmed with set port 20, vlan 1 tagged, set port 34 vlan 2 untagged. (ie. a little lower than what you are proposing).
But the company that makes almost all the switch hardware chips (Broadcom) have big huge NDAs in front of any of that stuff (I've looked before in the past.. :) The other makers are the big boys (ie. Cisco, Brocade, etc) that would never tell you how their hardware works.
Maybe you could look deep into the OpenSwitch people's stuff (ie. run linux as the control plane on switch hardware) to see how they do it.