Examples:

1. When tab-completing a selector for the first argument, it is not yet known whether it will be for the destination argument or for the targets argument, so it cannot predict whether the selector may return more than one entity, like it currently does for /data get entity
2. For

/teleport <location> facing <facingEntity> and /teleport <location> facing <facingLocation>,

typing

/teleport 0 10 1 f

will highlight 0 in light blue and 10 1 f in red and not allow tab-completion of f to facing. This is because it considers 0, as a player name, to be a valid argument (for the /teleport <destination>, different to the one we are writing out right now) and will not tab-complete the valid argument - see MC-123557.
3. For

/teleport <destination> facing <facingEntity> and /teleport <destination> facing <facingLocation>,

typing

/teleport @e[type=pig,limit=1]

with a trailing space will tab-complete to add facing at the end, however /teleport @e[type=pig,limit=1] f will not tab-complete f to facing. This is again because it considers f, as a player name, to be a valid argument (for the command /teleport <targets> <destination>, different from the one we are writing out right now) and will not tab-complete the valid argument - see MC-123557.
4. Trying to run

/tp @p 0 10 0 facing @e[type=pig]

will fail with "Expected literal facing at position 6: tp @p <--[HERE]" when I was actually meant to run /tp @p 0 10 0 facing @e[type=pig,limit=1].

Fixing this issue would also fix the current inability to change rotation when teleporting to coordinates, currently rotation can only be changed when teleporting to an entity target.

Suggested (partial) solutions to this issue:

• Split /teleport into subcommands like /execute
• Split /teleport into multiple commands: /teleport, /face, /rotate (or a subset of these 3)
• Introduce more keyword literals to /teleport to distinguish between coordinates and entities (like it was already done for facing)
• Make the targets argument non-optional