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: 
Best thing is to have a meeting and **lay out the pros and cons** as a group, and based on that discuss the best solution. If you have a team, get them to agree on solution. Once a team agrees on something, managers and "bosses" tend to go with the solution. 

If your boss still does not agree, then you've done all you can do: you've gotten your team and managers together and covered the pros and cons and despite that your boss chose a potentially inferior solution.

The key to this is discussing the pros and cons as a group. By doing so you are discussing what the best solution is with your team, and at the same time are pointing out your boss's decision (before he makes it) without the political backlash of going around after the fact telling people why you think your bosses decision was the wrong one.

This is a tender situation involving work politics, but it can be handled amicably.
You could tell the boss that while it's technically possible, it will cost *X* amount in time and money spent on effort on analysis, design, to rewrite existing code, testing, regression testing, ... And then ask if the feature is worth it. Sometimes the answer will be "yes! we must have this!", sometimes it will be "no, I guess not".

If the feature being asked for violates some core principle of the application (such as "Add a blue button!" to a UI that is spec'd and designed to only have red buttons as per the customer's request) then I think it is OK to ask "Why?" and mention that it goes against the pre-established design.

In the end, almost everything is a "can do" (it may not not hard from a *technical* point of view to add a red button to a blue-only UI), it's more a question of "should do?"

---

To answer your edited question, I think the answer should be #2, "Maybe", pending further investigation and analysis.

You don't want to answer #1 "Yes, unconditionally" because you could get stuck committing to something you're not capable of delivering in the given timeframe. 

You don't want to answer #3 "No, it's too much work" because then it looks like you are being uncooperative and needlessly difficult.