- The approval smart value returns the decision in case of Approval completed events.
- When we implement smart-values with sub-fields like approval, we pick one of the fields as the ‘default’.
- In this case the ‘decision’ field is the default. 
- So typing {{approval}} is the same as {{approval.decision}}. Our docs currently say that the approval smart value returns the name of the approval.
- In other words {{approval}} returns the ‘decision’.
- Furthermore, {{approval.decision}} only works for approval completed events so its values are APPROVED and REJECTED only.
- For "Approval Required" events we don't receive name of the event, hence we chose to show Waiting for approval there for {{approval}}.

I don't believe that this approach is most suited. Can you please assist us in working out the following issues?

In this way, approval returns two different values depending on the trigger being Approval required or Approval completed - https://support.atlassian.com/cloud-automation/docs/jira-automation-triggers/#Approval-required. 
- Is this not bringing unnecessary complication?

If a user is looking for a decision, they can always use {{approval.decision}}. 
Why we should have both approval and {{approval.decision}} returns the decision upon using Approval completed trigger?

Similarly, user can work out approval status (as you called in the documentation Waiting for approval) from {{approval.completedDate}} being null.

Assuming multiple approvals exist in a workflow (and all of them transition to the same status), how can I check which approval triggered the automation? Can we have approval.name or something?

In another word and to explain a little bit further about the above discussion,
Given that it is not possible - https://support.atlassian.com/cloud-automation/docs/jira-automation-triggers/#Approval-required -  to use Approval required or Approval completed triggers in one automation, there are two possibilities/pathways can occur:
 - If trigger is Approval required -> {{approval}} always returns “Waiting for approval” which we already know due to the trigger being approval required (meaning approval is not completed)
 - If trigger is Approval completed -> {{approval}} always returns decision which is already available through {{approval.decision}} [APPROVED / REJECTED]

To my understanding, this approach makes the approval variable unnecessary and meaningless, does it not?
I would appreciate if you can discuss it internally and help us to work out this issue.