The PAE does not change but I would expect the target position to rotate around the reference star at sidereal rate on the sensor. Same as field rotation.
Anyay I just did a back of envelope calculation. Similar to field rotation the rotation amount is proportional to the length of the vector which has the length of the PAE. So lets say 10 arcmin. And at a pixel scale of say, 1"/pixel the vector is 600 pixels long. After 1 minute the correct target position would move through an ARC of 15' or 0.0044 radians so r.x = 600 * 0.0044 pixels = 2.6 pixels
So the nett error in the alt az corrections would be 2.6" i.e. the resulting PAE would be 2.6" if the adjustments moved the star precisely to the target position - which is insignificant.

If the PAE was, say, 60' the resultant error would be 15.7" and still fairly insignificant. And if it then took 10 minutes to adjust, instead of 1 minute then the error would be 2.6'
So in that case the user would still a see a PAE of 2.6' even after doing a "perfect" polar alignment - still not a major problem except for the OCD.
So I would conclude that the rotation is not a significant problem. But maybe something users should be aware of that they should perform the corrections in good time.

I really don't see this as an issue. Since, even if a small error is incurred by taking a extra time to adjust, it will still be better than it was. Meaning, if you do two or three iterations, as one should, you will converge on an excellent alignment. With each adjustment being smaller, and quicker than the last.

Darn! Yes, you're right of course. Didn't think of the fact that due to PAE the sky coordinate grid on your camera rotates

Its not caused by the PAE (unlike field rotaion) - just the normal rotation of the sensor with an EQ mount. If, when the camera is pointing to the east (HA 18h) the top of the sensor is pointing terrestrial east. At HA 0h the top of the sensor point upwards in terrestrial. When the camera points west (HA 6h) the top of the sensor is pointing terrestrial west. So if you need to adjust in azimuth to the east on the mount then the target point on the sensor is above the reference star is the camera is poiting at HA 18h, to the left of the reference star when the camera is pointing at HA 0h and below the reference star at HA 6h.
As I've shown it is not a significant problem but its always worth doing the maths to be sure. No doubt someone will post one day something like "I did a PA using Ekos and got to < 0.1 arcminute PAE, then I checked in Sharpcap and PHD2 and it was DIFFERENT!!!!"

Then - No. Unless I'm missunderstanding it, what you describe is (again) the variation of the AltAz decomposition, and I tried to explain above why that is only a 'cosmetic' problem. The celestial N-S E-W direction in the camera frame does not change as you point anywhere at the sky. And with that, also the pixel to which you have to move the star will stay the same. What really changes the RA-DEC coordinate grid on your sensor is image rotation and/or drift due to PAE. But that is an order of magnitude less than what you compute, IMO.

Oh, and of course, a very badly tracking mount will also cause errors, as it 'shifts' the star position without you doing anything.

I'd say the upshot is if you have to do a quite large correction, always do a second iteration...

Here's a picture to explain the rotation. As I said, having done the maths it is not a big problem but one should always do the maths to be sure.
The picture shows the camera orientation as the mount rotates. The PA correction is constant in terrestrial coordinates (red to green spots). But that correction vector rotates on the sensor as the reference star moves across the sky.
The effect of the PAE is to lengthen the vector and thereby the arc length but except for a zero length vector the rotation is always there.

Now I tried out both the near pole and far from pole options last night. I am in the southern hemisphere. A possible issue with auto slewing that I need to delve into so I used manual rotation for now.
As an aside re auto slewing, I encountered a similar problem with the SPA tool in PHD2 in that the only simple way to rotate is with a goto. But that is affected by the sky model in the mount which causes some dec motor movement as well as RA so the mount does not trace a circle. The only way to be certain of RA motor only is a timed slew. Clearing the sky model should work also but I need to check - could be mount dependent.

So with the far from pole option the tool asked me to slew the mount literally a million degrees ("Please rotate your mount about 1e+06 deg in RA"). Log file attached for the align module.
I naturally ignored that.
The PAE reported was near enough, given that I slewed only a relatively small angle, so I did not adjust. The only other issue was that on completion the tool parked the mount. Given that I started the alignment in a state of unparked, having manually slewed the mount away from the pole, that felt wrong.


I haven't analysed the near pole alignment log yet so that will follow in another post

Q: What's white and black and goes 1,000 km/hr?
A: A Stellarvue in a blender.

Sorry, but your plot has several errors. Then math doesn't help. But I'm out here now....

With the close to pole alignment, I was asked to slew 89260.7 degrees in RA then 279141 degrees. I slewed manually a sensible amount and the magnitude of the PAE reported looked about right. I didn't check the orientation though.
Log attached

Just as well I have an M-Uno with a slip ring. I could rotate 1 million degrees if I had to

A million degrees! That's crazy. I checked the code but nothing stands out. It just takes whatever degree you put in the spin box. English is the current locale, right?

Regarding the motion itself, you don't to worry about alignment, the mount is commanded WEST/EAST directly, not via GOTO, so no chances of DEC playing a role here.