Question: What is a good attitude from developers when discussing new features, and namely, non critical/questionable features?

Say you are developing some sort of Java like language, and the boss says: "We need pointers so that developers could fiddle with object memory directly!"

Should the developer shoot down the idea because it adds unimaginable complexity and security vulnerabilities, or should he do what's asked?

This may not be a good example, but what about things that are more in a gray area, like adding buttons that break workflow, or goes against internal structure of the program, etc.?

What is the optimal "can do" vs. "can't do" distribution for a regular programmer?

EDIT: The question is not about a bad boss :D

I was more interested how do people approach new problems that add a noticeable amount of problems while maybe being marginally useful.

Should the general attitude be:

1. yes we'll do it, screw the complexity
2. maybe
3. no, the general rework, and implications don't justify the change

What should be the reaction of a good developer?

Answer: 
If you spend many years programming for large applications, and think critically about it along the way, you will develop a finely tuned sense of when a feature is going to cause problems that outweigh its usefulness. Another word for this is *wisdom*, and just as is the case with other kinds of wisdom, it can be a challenge to make those without it see its value.

Other posters have argued that you should try to quantify the cost of the problem that will be introduced by a problematic feature, and that is a good idea when it is possible, but usually it is not. It is usually only possible to estimate immediate implementation costs. Even that is often difficult for larger features. As for the future costs, you are in a tough spot. You don't know with certainty what other features will be required, or how long the product will be under maintenance. The cost will usually be much higher than you could back up with an estimate based on hard facts.

The more competence you have demonstrated in the past, the more leeway you will have to simply declare a feature a bad idea. That can only come with time and a demonstrated record of success. That said, you should always express eagerness to fulfill the request, since it is what your client wants. You should express reservations based on your experience, and once you have, it becomes a non-issue in 90% of cases because you will start a conversation that gets to the root of the issue, which is: Why have they asked you to add this feature in the first place? At that point you can offer alternatives, or perhaps agree that although the requested feature will introduce problems, it is still necessary.

Of course it is also possible that you are just wrong. Isn't software engineering fun?
If you are in the position to understand the cons of doing it (complexity, lack of usability, etc.), then it is in everyone's best interest for you to explain it to the best of your ability. Often non-developers do not understand the problems of adding new features. It's easy for them because they don't have to do anything or even think about it.

However, if the powers that be decide that the new feature is going to be added, then you should do the best job possible. It's a challenge.

And, if the new feature is too stupid or the working environment too crappy, then it's time to find another job.