Not in Hubitat. The name doesn't really mean all that much. You can modify the name all you want. It's the device ID that is locked to the device. So, your discussion about IP address vs MAC addresses is completely moot as far as Hubitat is concerned.
But Zigbee already exists. 
I'm not sure what systems you're working with, but on Hubitat it doesn't matter--as stated above, the device gets a unique ID in the Hubitat database, which you cannot change, and for most things, that's all that really matters. To replace one device of any type with another of any time (including the same type) would require some sort of "replace" feature on Hubitat's end--something some people have asked for, but I don't believe staff have stated whether they plan to implement this or not. (Z-Wave requires this capability for certified devices, which Hubitat is not currently, but that still won't help with other protocols.) As-is, you'll have to swap out the device in all of your apps/automations regardless.
Some things on Hubitat (and I'm not sure this includes any stock apps) rely on the device's DNI, which is user-changeable but should be done only with extreme caution; for LAN devices, these are sometimes based on IP or MAC or another unique-to-that-app/driver identifier. This is usually not helpful, though I have swapped out Hue bulbs on a Hue Bridge, figured out the DNI convention (involves the Bridge-assigned bulb ID), and was able to swap DNIs around in Hubitat and make it think the new device was the old one. I would not recommend this unsupported path for most cases. 
This is why I use Hubitat as a bridge so I don't need to write code for every device myself.
Zigbee is an old style silo protocol that doesn't scale beyond the home whereas, using shims such as port forwarding, I can connect to the devices from anywhere in the world.
I do use Z-Wave, Zigbee, Hue, Yeelight, Insteon etc. with Hubitat as my connector to the first four (though I had to do some of my own Yeelight support for some devices).
I might be reading too much into what you're writing, but get the feeling that you are on to something I've been pondering.
If you have the time, please read this post about device abstraction I once wrote on the ST forum and let me know 
I'll need read your post in more detail when I'm not dealing with crises-already-in-progress. I'm working on my next column and the focus (or this or the next one) will be on connectivity protocols independent of the underlying technology.
One example is describing a screen involving a number of light sources -- intresting question about where the knowledge exists and how to manage the relationships. Even more complex when you want to say "provide light" and include opening the shades to use sunlight as an option and then saying color temperature is or is not important for the particular needs.
This is one reason I'm decoupling from particulars such as a Hubitat or ST rule set which are built around particular solutions.
Very much research-in-progress (hence crises-in-progress).
1 Like
FYI...The built in Lifx integration is now available in the latest version. Check out the release notes here:
1 Like
