since that attribute would be the unique trigger for the automation, using trigger.attribute would also be unique, and couldnt be confused with any other attribute of the state object.
currently the trigger.to_state part of that refers to the trigger (obviously), but then we need to spell out the attribute.
this FR would solve that mixed referencing syntax, and make it a lot easier to copy the automation body for different attributes elsewhere
to_state and from_state contain the entity’s complete State Object before and after the state-change, respectively.
According to your proposal, trigger.attribute would contain the monitored attribute’s new value. In other words, it duplicates trigger.to_state.attributes.foo but only if the State Trigger is configured to monitor an attribute named foo.
trigger.attribute seems like it has a very narrow use-case and is more “mixed syntax” than the status quo.
If the goal is to simplify the variable’s name, then I suggest that trigger.value could be used to represent the new value regardless if the State Trigger is configured to monitor the entity’s state or one of its attributes. In other words, trigger.value is the same as trigger.to_state.attributes.foo or trigger.to_state.state, depending on what the State Trigger is configured to monitor.