If you read Seth Godins blog (http://sethgodin.typepad.com/) you will see the same message coming through over and over:
- Ship something (and listen to the feedback)
- Don't try and please all the people all the time.
I've had a similar issue to you with a product I sell. I've had all sorts of requests for all sorts of features. The application has grown to be more complex than I really wanted. Every option adds complexity, something I wanted to avoid. And now I have more complexity than I would like.
Doing this pleases more users. And drives away users who find it to be too hard to set up.
Having simple/advanced setup is a way out of the bind. Up to a point. It makes your development more complex, though.
In all cases where I get a request, I always reply politely. Sometimes I will outright refuse, though this is rare. And where I do this I explain why, usually it would be in response to a request that would require the entire UI to be revamped, an undertaking so massive I just won't go there. In that case I explain my reasons, but thank the user for the request.
In ALL cases, including those I reject immediately, I log them in the features & defects database for consideration for the next release. This allows a bit more time to think about it all, and perhaps come up later with an alternative thats not exactly what was requested but might add some value.
If a feature request has been considered, annotated, and a decision is finally (at development time) made to kill it, then I close it. Otherwise they get left open for reconsideration later.
This is not a perfect approach, but in the end as the software author you have certain design principles that you need to either stick with or abandon. The choice of each approach should be carefully considered.