For your information; it looks like a zigpy developer now started work on stand-alone and external implementations of the ZHA integration (i.e. the built-in native Zigbee gateway implementation) for Home Assistant:
https://github.com/zigpy/zha (see zigpy/zha#6 if want to get an developers overview)
And this matching fork of a new ZHA integration component for Home Assistant broken out and using said stand-alone and external implementation of “ZHA Gateway”:
https://github.com/dmulcahey/home-assistant/tree/dm/zha-external-zha
Note! It is very much a work-in-progress. Initial port seams done but “things will be broken for a while”.
Still it looks like they have come along far with this new concept, and looks initially to be a forked and restructured variant of Home Assistant’s zha component that is converted into a standalone program:
https://github.com/home-assistant/core/tree/dev/homeassistant/components/zha
For reference; the ZHA integration depends on libraries from the zigpy project but the Zigbee gateway implementation that is the is ZHA integration is today a built-into Home Assistant core, which means it can not be updated or maintained separately and it stops running when to stop or restart the Home Asistant core.
I guess this idea to split out the ZHA component from Home Assistant core has grown from a previous concept that the same developer(s) began working on couple years ago with a zha-websocket-server and zha-ws client addon/plugin for Home Assistant.
https://github.com/zigpy/zha-websocket-server
https://github.com/zigpy/zhaws-addon
https://github.com/dmulcahey/home-assistant/tree/dm/zha-ws
https://github.com/dmulcahey/home-assistant/tree/dm/zha-ws/homeassistant/components/zhaws
I assume the goal will to breakout the zha component from Home Assistant core and make it an external Zigbee gateway application that can be updated separately from Home Assistant core and in theory also enable it to be used as a stand-alone and/or external version of ZHA as Zigbee gateway implementations by others in other third-party projects which then could make their own integrations and/or different UI frontends for that stand-alone version of zha, (probably accessed via websocket).
As splitting the Zigbee gateway application implemnentation part in the zha component away from the Home Assistant core will allow you to run “ZHA Gateway” externally, either as an addon or even stand-alone on a different computer, with it only communicating with the new ZHA integration in Home Assistant using websocket (which can be done over a local network). Today this is probably the most common argument why you might still want to recommend Zigbee2MQTT instead of Home Assistant’s built-in native ZHA integration to a brand new Zigbee user (as Z2M and ZHA today otherwise compare equally in features and functions).
Another bonus is that it could potentially in the future also eanble users to have multiple instanses of external ZHA Gateway servers (each with its own Zigbee Coorinator radio adapter only controlling its own seperate Zigbee network), allowing users to for example have a “production Zigbee network” and a “test Zigbee network” (to seperate the testing of new and troublesome Zigbee devides).
PS: If this case the result will likely become very similar to the “Z-Wave JS” (node-zwave-js) project which uses a similar client–server model (also known as “frontend-backend model”) distributed application structure architecture for its different implementations which depends on an addon (plugin) and external server program that can also be used as a stand-alone application. For reference check out the Z-Wave JS integration and related projects :
https://www.home-assistant.io/integrations/zwave_js/
https://github.com/home-assistant/addons/tree/master/zwave_js
https://github.com/zwave-js/node-zwave-js