The unfortunate truth is that better than ninety percent of feature requests from users are not useful to us. We think this is a shame, for two reasons. The first is users ought to be able to get the features they want--and the second is we want to give users the features they want.
When talking about architecture, it doesn't make much sense to talk about a window by itself. You have to talk about how the window will affect the people who live there--will it make the room brighter, or will it make it too bright? You have to talk about the building itself--if you put a window there, will it mean you have to take out a support beam?
Software is the exact same way. There are tradeoffs that have to be considered. It takes a lot of training, skill and experience to understand how these decisions will affect each other and the finished product.
Feature requests like "the key generation wizard should act like this" are, generally speaking, not all that useful to us. Maybe you think it should act that way--maybe we agree it would be nice if it acted that way--but we might know that it can't work that way. That leads us to dismissing your request on the grounds of "we can't do that", with a side of "and it's not a problem anyway, otherwise they would have said there was a problem."
But if you say "the key generation wizard always confuses me when I'm selecting a key size. It's confusing because ...", then suddenly we sit up and take notice. There's a problem! A user, a real user, is telling us there's a thing that needs to be fixed! Once you phrase things that way, the help staff will begin trying to help you find an interim solution, the UI staff will see if the problem can be fixed, the coding staff will put it in their work queue... things will get fixed that way, and maybe fixed a lot faster than you think.
Feature requests should tell us the problem you're having and what ultimate outcome you want. Let us worry about the hard stuff, like how to actually do it.