My programmer brain is thinking, "just plug it in as new content for the following 7 days after any additional activity".

Something like this already exists. See eversteem (Introduced here). But, we're back to relying on beneficiary rewards in order to make it work.

The original posting account can't create the new content because the front end and the blockchain don't have access to the original account's keys. So, the new post has to be created by a different account with beneficiary settings pointing back to the original author and the new post would be the one that receives votes.

I never got past the language barrier to really understand how that site works in detail, but a front end could definitely create a new post whenever activity happens and manage the abstraction to make it all look like a single post.

Which relates to your other reply:

I get your point with beneficiary rewards.

I just think that has a high potential to go nowhere. It's too technical to be successful at scale.

Yes and no. I agree that we can't realistically ask users to remember to update their beneficiary settings with every post, but the beneficiary settings can be automated (as-is done by Thoth & EverSteem) so that it doesn't add complexity for the end-user.

A simple example is that the front-end could set all replies so that a certain percentage of rewards go back to the original post's author or the author of the parent post. All the user would have to do is set or accept the default. Another example would be to link the "resteem" and the "comment" operations (like a Twitter quote retweet) and set the beneficiary settings appropriately on the comment.

Front-end developers have soo much flexibility here, and they're just not making use of it. I think this should almost be pri-1 for any/all developers who aren't working on the blockchain's core code (which is why I made Thoth my own pri-1 project).