Need ability to create and link issues as part of a workflow

I would like to add transitions to a workflow that let you do the following. They all sound like different requests, but I believe they all have a common thread, so I'll link them together.

1. When resolving an issue as duplicate, you should be able to specify one or more issue numbers that this issue is duplicating. It should create "duplicates" links to each of the issues.
2. It should be possible to create a transition that can create another issue based on the current issue, and link the two. (Better explanation below.)
3. It should be possible to create a transition that will perform an action on a linked issue. (Better explanation below.)

Imagine a scenario like this. We have an external "Bug Reports" project, and an internal "Development" project. When an issue is reported into the "Bug Reports" project, it will have a reporter and some people who are "watchers" on it. At some point the issue may become a "confirmed" bug, and we want to move it to development. But we don't really want to completely MOVE it, because we still want it to show up under the old number in the "Bug Reports" database. Instead, we want a transition that does the following:

1. Sets the status of the "Bug Reports" issue to "In Development"
2. Creates a clone of an issue, into another project ("Clone and Move", which is a feature you don't really support.)
3. Links the two issues using a link type of our choosing ("is tracking" / "is tracked by" or something like that).

Now, this new issue in the "Development" project can have a completely independent status, version, and everything else, and watchers of the original issue aren't notified when it actually moves from "Open" to "In Progress", or if we schedule it for the next release, but then change our minds.

When we then finish testing the "Development" issue, we'd like to create a transition like "Release" that will then modify the original linked "Bug Reports" issue, like changing the status to Fixed and adding a comment that says what version it was released in.

This concept of linked issues is important for many companies. I applaud Atlassian for being so open as to use the same internal and external tracking systems, but I don't think most companies can get away with this. Let me reiterate some of the problems. For us in development, resolving an issue as fixed doesn't mean it is ready to deliver to a customer. It then needs to be code reviewed, and then integrated to the main branch, and then tested by QA. And we need documentation for it, and so on. In many cases, we may fix an issue, but then decide we don't have time to test it adequately, or it is too risky for the next release, so we pull it and do it later. If customers actually saw some of this process, they would blow a gasket. "You told me it would be fixed in the next release!" And by "customers", I don't even mean only external ones either, I will include our own sales and support personnel, who will pass the information on to customers even if it isn't in an outward facing system.

I guess what I am trying to say is, you have this workflow system, and you have this concept of linking issues, but the two features are totally disconnected. Being able to create a new linked JIRA issue, or modify linked issues, seems like a very fundamental thing a workflow should allow.