Indeed I do think this is a complicated area as you would not want the user to be "tricked" by a new UI that apparently "changes the rules" (although the underlying rules in the AT themselves cannot be changed).
For sure I would not want to see UI upgraded "automatically" (it would need to be up to each user to decide) and perhaps there would need to even some sort of majority agreement amongst nodes to accept any change.
The case in point that lead me to ponder this was the CF AT which currently displays "Pledge" even when the CF has reached 100% (arguably it should show "Donate" after this point even before the target block is reached).
Such a UI update would not alter the function of the AT at all but I do agree that some other change might not be as acceptable. Another possible idea is that you could choose to use the original UI always (if you don't trust any updated UI).
This is one of the main reasons why I think that UI needs to be implemented using metadata rather than any "code" in the AT.
Also with metadata I think it might be easy enough to recognise "display only" changes (i.e. not functional ones) which should be harmless enough to permit.
Fundamentally the "real interface" is defined by the AT itself in terms of the "txs and messages" it processes - so you could actually allow for multiple UIs for the same AT (none should be able to cause any trouble so let the users work out which they like the most).
Even "display only" changes can be dangerous, such as swapping the labels on buttons to make users choose the wrong choice.
Any sort of offering multiple interfaces complicates things for the end user, who is most likely to accept the most recent version without considering the consequences or comparing the differences. People are already blindly trusting ATs that they haven't looked at the code at, and I wouldn't expect any better for interface metadata.