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: 
I believe in pushing back bad requirements. But I also believe that when you have given your best shot at explaining why they are bad and they still want them, then you agree and do your job. 

For instance, I have had people who want requirements that were mutually exclusive of something the application already does. If I do that, then this will, 100% guaranteed, break. So I send the requirement back and tell them that this will break this other business rule we already have in place and do they want to change this rule too? Often the small group which comes up with a particular requirement doesn't have access to the bigger picture of what the rest of the application may do. Most of the time when I've sent one of these back, the customer has realized that the intial rule was more critical and decided that the change they wanted wasn't worth it. When they have decided to make the change they did it after consulting with the people who pushed the initial requirement. 

Sometimes just asking clarification questions will make them see the issue is not as simple as they thought it was. Sometimes you want to ask why they want something and come to the real need that is driving the change. Once you understand that, it is often easier to see an alternatve solution that works for you as the developer and meets their need. If you can present that solution in terms of how it will better meet their need than the orginial suggestion, you have vastly improved your chances of having your change accepted.

Sometimes when a change is going to create havoc at a basic level in your design, just giving them the new estimate of hours the change will take is enough to get it turned off. If you combine that with a risk assessment that points out what critical functionality you might be introducing new bugs into with telling them it will take 6 weeks of dedicated effort by 3 people, suddenly it isn't so important any more. 

But sometimes you tell them this isn't a good idea and why and they still say, "Too bad we need it." You win some and you lose some and sometimes the business needs genuinely have changed and the application must accomodate that. Once the decision has been finalized, it is no longer the time to question what you are doing and time to get on with doing it. If you have documented your objections, then you personally should still be in a good place when it goes over budget and causes new and more exciting bugs. And they might even be more willing to listen to you next time when you have built up a track record of being right on these sorts of things. 

The key to winning many of these discussions (nobody wins all of them) is first to build up a track record for knowing what you are talking about. Next send a written document that states what concerns you have (many managers are risk adverse, they are more likely to not want someone to have a document that proves them wrong later, so they pay more attention to what you put in writing) and finally to make sure they understand all the costs (not just hours, but security risks, introducing new bugs, missing deadlines, etc.) of making the change. Change is not free and they need to understand that. The next key is to do this like an adult and not like a whining child ("but I don't wanna use ... because I don't like it"). Make a business case for not doing it and you will get a lot farther in pushing back a bad requirement.
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.