Just wanted to wrap up this topic so that is someone sees this later they don't feel it is a total dead end..
It was Wordfence that was causing the problem.
What is interesting is two things: 1) When I originally started this part of the project, the basic proform was working fine and Wordfence was active, it appeared to suddenly stop working one day. My assumption is that I did an update of that plugin and that introduced the issue. 2) that it does not have to be active. Its very existence causes the problem. I searched for that type of issue, (i.e. deactivated plugins causing compatibility problems) and did not find anything..
It was my assumption, clearly wrong in this case, that deactivating it brought it out of play. Well, in the case of Wordfence, not so!
It was suggested by Cristian in another thread on a related issue that it is the MU plugin that Wordfence was probably installing that is the cause of it interfering even though not active. I have NOT confirmed this yet, but it is a possibility.
What I did find though, concerns me long term, as far as stability of the basic s2member subscription process. What I mean is that any 404 or other failed resource would/could trigger a re-firing of the "init" functions on that page. It seems that the dependency of using the "init" to fire the checkout code is risky (and not something that is easy to discover) and is not something even you suspected (which leads me to suspect that this technique is not common knowledge??). It appears that Wordfence does something, possibly in the MU plugin that triggers this re-call of the page because it is clear from my research that this is exactly what was happening.
Here is the link I found that matches the data I collected.. (Though note, that in tracking the network traffic, the browser did not detect any 404 errors, therefore it may be something Wordfence is doing locally on the server. The effect appears to be the same regardless.)
I hope this helps someone else that encounters this issue/mystery...