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: 
From the perspective of a developer: NEVER tell anybody paying the bills that they can't have what they want. Instead, you may tell them they can't have it for that price, or that they can't have it exactly the way they originally conceived it.

To your "pointer" example; .NET, a managed-code environment, has pointers. They are critically necessary for a lot of interoperability with unmanaged code. However, "safe" use of them is tightly regulated, and if used in "unsafe" code, that code requires higher security permissions in the runtime. If you were developing a managed language that also required direct memory access via pointers, you could come up with a similar scheme of marshalling behind the scenes where you could, using read-only managed pointers where you couldn't automatically marshal, and allowing "true" pointers only in the most trusted areas of the codebase.

To your GUI examples: if you know that a new feature will "break" the current flow of code, then you can test for that and develop it more robustly to roll back any previous work done by the workflow. Your clients, and sometimes even your manager, usually have no clue or interest in the structure of the program; if something they want is difficult because of the way you structured the program, then by definition the structure is wrong because it does not allow you to do what the client wants.

In all cases, this new feature may increase the scope of work required beyond what the client had thought it would be. That will in turn require either an extension to the schedule, more money, and/or a reduction of other planned work.

However, if you know a way to achieve the same basic result in an easier or more logical way, then that can be suggested to the client. Although they definitely do exist, I fortunately have yet to see a client that refused categorically to listen to input from developers, especially in an Agile environment where there's a "product owner" whose sole job is to liase with development on various needed details such as these.
Excuse me, but this question sounds like a minor asking for fatherly advice. If this is the case, the good developer will need to embrace these commandments:

* Remain faithful to yourself. If your gut feels uneasy about a feature, voice your concerns audibly. Chances are good that the team is just awaiting an opening.
* Do not try to substitute experience with the rules of thumb of the experienced. To you, every situation is different, every feature is new. This is a plus your seniors don't have.
* Software development isn't exact science, it will never be. Therefore, accumulate wisdom, not behaviour.
* Accept defeat. If the team agrees otherwise, do not repeat your concerns ad nauseam.
* Think positive. If the idea is really begging for 'shooting it down', try to find and name positive aspects to it before you list its deficiencies.
* Learn how to interact with people. We developers often place technical knowledge over social competence. The technical abilities peak early in life, but the social competence can keep growing until retirement.