Depending on whether or not the HA devs will be able to transition existing native z-wave users to the mqtt version could be a reason (or not) to switch to zwave2mqtt now. But I do not think zwave2mqtt will be compatible at all with qt-openzwave, so you’ll need to choose one or the other, or transition again later.
I will wait for the natively supported solution. qt-openzwave is written by the OZW dev and uses the C++ API directly, thus it is less immune to breaking API changes. zwave2mqtt is written using the NodeJS wrapper library. It suffers the same problems as the python library, which is breaking changes to the API need major changes in the wrapper libraries (it’s the problem we have today). If the node-openzwave-shared developers and/or the zwave2mqtt developers dissappear one day, you are in the same predicament as HA is today. In fact, it is unclear to me how much support zwave2mqtt has for OZW 1.6 at the moment.
No offense to the zwave2mqtt dev, who is doing great work, but the OZW dev has much more experience with z-wave in general, and more experience with a broad range of z-wave devices. I trust that will reflect in the quality of the qt-openzwave project.
I feel more confident that the qt-openzwave project will be maintained along with the OZW library in the future. I think it’s the whole point of HA going with this approach. Another benefit is that by going with MQTT, it has a much lower barrier of entry to other HA devs. Instead of having to know the intricacies of the OZW C++ API, wrapping it in a python API, and then understanding the wrapper, you are mostly dealing with MQTT. I’d reckon there are many more devs who can deal with MQTT and the topics qt-openzwave is providing than there are who understand the OZW APIs.