Well, from testing in uutai1, it seems fairly easy to work out what it's doing. PC informs the system of which
entity, and hence which field object, animations and scripts represents which character ID, since it needs to know, for example, which entity is to represent Cloud (PC 0). The argument, then, is just the standard character ID that the entity is to represent.
If you switch, for example, Cloud's PC argument with Cait Sith's (0 to 6 for Cloud, 6 to 0 for Cait), then Cait Sith becomes the controllable character with all the correct animations (he bounces as he walks rather than uses Cloud's running anims). This is because instead of the CLOUD entity, field object, and all its animations being the main playable character, the system recognises the KETCY entity, with its field object and animations (and scripts, I would assume) as the main playable character since the current leader is set (again, I would assume within the kernel or some such) to be PC 0, due to the fact that the PC (0) opcode now resides in the KETCY entity. This is obviously not just "who is in the top row of the party" since Cloud can be moved up or down the list and he is still recognised as leader.
During the times when Cloud is not the team leader, either Tifa or Cid becomes the playable character. Presumably this is set somewhere within the system such that PC (2) or PC (8 ), respectively, is the team leader rather than Cloud's PC (0). So let's say Tifa is now the leader; when a field is entered, the field module knows that it should look for the entity with PC (2) to be the leader. When it finds this opcode/argument, it then knows to use this entity's field object and animation set (as well as script set) to be the controllable character.
Make sense?
[Edit] Silly smiley
