That behavior is exactly correct. NamePlate1 is always associated with the unit "nameplate1". However, "nameplate1" can be associated with different units at different times, because nameplates are dynamically assigned. That is, UnitIsUnit("nameplate1", "target") can change from true to false even if you don't switch targets -- simply because the nameplates got rearranged. Currently, all nameplates get refreshed whenever any CVar changes (hence the behavior you're seeing with changing the nameplate settings).

That behavior is exactly correct. NamePlate1 is always associated with the unit "nameplate1". However, "nameplate1" can be associated with different units at different times, because nameplates are dynamically assigned. That is, UnitIsUnit("nameplate1", "target") can change from true to false even if you don't switch targets -- simply because the nameplates got rearranged. Currently, all nameplates get refreshed whenever any CVar changes (hence the behavior you're seeing with changing the nameplate settings).

This is pretty dumb, because then you can never know when is your unitID is gonna get rearranged to something else. You can't hook every cvar change, and there is no event to listen.

Edit: It seems like cvar updates trigger the NAME_PLATE_UNIT_ADDED, NAME_PLATE_UNIT_REMOVED events so it's gucci if you update based on those.

some style options for units will also have to be independently updated with a more aggressive hook — the castbar has to be reconfigured more or less every time it is shown if you want to change its size etc. i think.

Edit: Raidframes work the exact same way, if you rearrange your raid group & switch your main tank from group 3 into group 1 the unitID for this tank also changes...

Yes, but in partyframes UnitButton1 will always retun the "party1" unit attribute and even if you create a secure header with 1 single group and 30 unit columns UnitButton25 will always have the "party25" attribute, and so on. Here however seems like UnitFrameX can have any random "nameplateY" attribute and randomly rearrange them time to time. Which is confusing and possible root of bugs.

Yes, but in partyframes UnitButton1 will always retun the "party1" unit attribute and even if you create a secure header with 1 single group and 30 unit columns UnitButton25 will always have the "party25" attribute, and so on. Here however seems like UnitFrameX can have any random "nameplateY" attribute and randomly rearrange them time to time. Which is confusing and possible root of bugs.

It's entirely possible I don't fully understand the problem, but could this be to prevent creation of accurate nameplate grids that allow for ridiculous micromanagement of debuffs? Instead of having to hunt and click moving nameplates, you could set a secureheader similar to what we do with party/raid frames, and never really have to look at the mobs, just your grid of clickable nameplates with debuffs and timers over their heads. By having them dynamically switch, it prevents this behavior, while still maintaining the accurate debuff tracking.

It's entirely possible I don't fully understand the problem, but could this be to prevent creation of accurate nameplate grids that allow for ridiculous micromanagement of debuffs? Instead of having to hunt and click moving nameplates, you could set a secureheader similar to what we do with party/raid frames, and never really have to look at the mobs, just your grid of clickable nameplates with debuffs and timers over their heads. By having them dynamically switch, it prevents this behavior, while still maintaining the accurate debuff tracking.

I don't know. I'm not sure what limitations this nameplate attribues have. You might be able to only track debuff/buffs on a plate that you have already targeted at least once. It would be intresting to create an unitframe and set a nameplate attribute for it, and check how does that works then.