Trainer Commands implements the @pl target selector which means "player that interacted with the pixelmon entity".
This provides the advantage over @p that the commands will always be executed on the right player (wheras with @p, a player could stand closer to the NPC than the interacting player, and the command would run on them instead).

Consider the following example - this is designed to give the interacting player a starter pokemon after interacting with an NPC. However, they will not receive additional starters by speaking to the NPC again, as they now have the tag "hasStarter":


Unfortunately, the implementation of @pl is achieved by text-replacing any instance of "@pl" with the interacting players username. This results in the first of the above commands attempting to run
This is not a valid target selector - a playername selector cannot contain any trailing data. As such, the command fails, and an error is produced in logs:


If the above @pl target selectors are swapped to simple @p target selectors, the commands are able to run as expected (however, this runs the risk of running on the wrong player, as mentioned above).

Steps to reproduce the issue:
1. Open a world with pixelmon 9.1.2 and trainer commands 2.6.0 installed
2. Place down an NPC, give them the following command

3. Interact with this entity, the error above is produced.
4. Place a new NPC and give them the same command as step 2, but this time with @pl arguments swapped for @p arguments

5. Interact with this NPC. After a short delay, the starter menu is displayed.

My latest.log from reproducing these steps: https://pastebin.com/fbcqeWuV
This was tested with the official pixelmon modpack, version 9.1.2, with trainercommands 2.6.0 added. Forge version was 36.2.34