I won’t defend the unresponsiveness of the s2Member devs, because there isn’t any good reason for that.
But, as for the code, you haven’t established that it isn’t working. In fact, all you’ves established to me is that you are running at least one plugin and probably your theme which isn’t coded to proper WordPress standards, and so prevents s2Member from working. It wouldn’t be at all surprising if one of those plugins or them has also polluted your .htaccess file.
It isn’t the responsibility of s2Member to try to overcome the deficiencies of other code that you’re running. If you had a testing site too (which you definitely should in any event) we could have tested the whole thing properly without messing with your live site, and saved you a lot of stress. But that isn’t s2Member’s fault either.
Your case is just an example of what I see a lot with people using WordPress. They want a particular look, so they start building their new site with a theme that looks good. They go to Themeforest, because that’s where lots of shiny themes are, and they think that paying for a theme means that it is better than a free one.
Unfortunately, that’s almost always a big mistake. Almost all the themes there are poorly coded (even the very well known ones) and it’s almost impossible to identify one that is well-coded until after purchase. But now you’re stuck with a theme which is going to give you problems throughout its life, and which probably comes bundled with plugins which suffer from yet more problems.
The new site owner doesn’t know this, of course, and the theme and bundled plugins work fine together (because that’s what they have been designed to do). But then the site owner wants to add some extra functionality with a new plugin. If this is minor stuff, s/he might be lucky. If it’s something more significant, though, the problems manifest themselves. But what gets the blame? The new plugin. After all, everything was working before. But the site owner is wrong. The problems are caused by the shiny theme and its bundled plugins.
The site owner finds it hard to accept what she’s told, because s/he believes the evidence of her own eyes. But those eyes don’t see the underlying code, and s/he’s too frustrated and upset to actually start from scratch. But code doesn’t compromise: it either works or it doesn’t. So attempts to compromise lead once more to inevitable failure.
The site owner talks about other plugins s/he’s added, which didn’t cause a problem. But those plugins didn’t add significant new functionality, so they didn’t impinge on the same code. But the site owner can’t believe it and wants his/her money back. The developer refuses because s/he knows her code is fine, so the site owner complains loudly to anyone who will listen. But the developer is right; it’s just that the only way to convince the site owner means the latter doing the very thing s/he doesn’t want to do: rebuilding the site from scratch.
No doubt you’re not persuaded, but this is the situation you are currently in. And, whether you’re persuaded or not, the truth is that those coding problems remain on your site, and will cause problems at various times for as long as you continue to use the plugins and/or theme in question.
If you ever build another site using WordPress, start with a free theme from wordpress.org. Even if it’s poorly coded, the fact that it’s free will make you feel less invested in it and therefore ready to drop it as and when necessary. (It also won’t come bundled with plugins.) But try to build the functionality first, and leave the decision about a theme until after you have that worked out.
