Thank you all for the feedback. It does confirm my fears.

1. It really is happening.
2. The behavior is new to SP3. Before SP3 it was not necessary to specify file extension in the DO command to get the PRG to execute after a MPR or SPR with the same name was executed. To be more accurate it is documented to looked for EXE, APP, FXP, then PRG in that order. (Of course it will recompile the PRG to an FXP if SET DEVELOPMENT is ON and the PRG is more recent then the FXP)
3. It still behaves the old way in a compiled application even under SP3. (Thankfully or the recent updates I sent out would have made my clients very unhappy.)

I knew that CLEAR PROGRAMS would resolve the problem but adding that command is not the solution I wanted to implement.

The best solution seems to be to rename the files names so they are unique. This will be a pain for some legacy code where the code snippets were kept in a program that called a screen which may have also called a menu all which had the same file names. (E.g. Client.PRG, Client.SPR, Client.MPR)

A further note...
I did some simple tests to make sure that this problem with FoxPro caching of PROGRAM names did not also affect PROCEDURE names. It would be more than inconvenient if procedure names had to be unique in an application. So far it appears to resolve procedure names as documented.