We have of course s2m Pro.
It still recommends ezphp, Jason’s other plugin, and for good reason: It’s brilliant. Where it works.
A user, Pam, here https://www.s2member.com/forums/topic/ezphp-not-working-extra-space/index.html
closed thread unfortunately,
nailed it already in the sunny year 2013 (let’s dream for a moment…)
and the issue is still the same in the cold year 2018 - and has garnered many user requests/complaints on wordpress.org, none of which have been answered unfortunately.
So I wanted to make a suggestion and updated request too:
Issue still exists: We add <?php blabla to an s2member page or not
and SOME post_content filter(??) introduced by the ueber sedulous wordpress coders in SOME update since 2012 or so…
ADDS a space character like so: < ?php
when a PAGE OR POST gets saved
which prevents code execution by the plugin!
I suppose it’s SOME post_content filter(??) because in WIDGETS the <?php is left UNtouched, it WORKS (for us at least).
I stress again (so that neither Raam nor Jason feels stressed): It clearly is NOT a fault of ezphp plugin as such, but rather of wordpress messing up Jason’s plugin code.
I myself have tried for what feels like 149 years (or: since Pam’s post in 2013) to identify the error but have not found it unfortunately - because I am no coder. Once I got darn close: It seemed it’s when the php eval() function is not activated on a server. However, it turned out, activating the eval() function does nothing to prevent this added space character. 
Suggestion now: How about one of this brilliant coder team here takes a good look at the code execution footprint when a page/post gets saved? Using one of coders’ bread-and-butter tools like maybe Inspector(?), and applying your wisdom to see what’s going on?
My guess: If someone can program sth as complex as s2member, then he can rapidly see why the space character gets added, and can suggest us how to prevent that.