I think you've already answered at least a good chunk of your own question:
Originally Posted by durangod
Row whopurchased (field which contains an array of userid's)
Never create a collection in a single field. Ever. So that means option b is out.
What you will have is a many to many (many featured can be used by many users). So what you will need for sures is the users, the feature, and the userfeature table (where the userfeature can be named whatever to indicate that it is purchased), so that's a minimum of three tables in order to flatten a many to many.
How you apply it though will be mostly programatically. With an example as you have posted, that would indicate that replying is always "free", but creating a topic would cost. So you would deal with that at the topic level, but not the reply level. If a post is always paid for, except where you have already payed for a reply would be done by simply collecting everything in topic, and if one post already exists than no charge is applied. All program controlled; SQL shouldn't be given the burden of too much of this (although you could use it to create a mustpay type field calculated off of the aggregate count from the query).