How should one measure Defect Density?

Is there a standard way of measuring Defect Density? Most sites online state that it should be measured as:

number of defects discovered / the code size

My questions are:

Should defects "fixed" during the period be subtracted from the defects discovered?
What should one do with the defects one decides to fix in the following release, due to lack of time? Should these backlog defects be added into the next release's density?
KLOC in the denominator is probably not a good measure if it has been proven that the code is unnecessarily bloated up due to heavy duplication. How should one factor that in?
Can one correlate the Churn in a particular period of time, and the existing backlog of defects for a particular module, to the number of defects created/discovered as a result of the Churn

Our ultimate goal is to be able (a) to compare our defect density against industry standards (b) to identify modules which are fragile and more buggy and deserve more attention (c) to use a consistent metric in order to draw a trend line demonstrating improvement in the quality of a module over time

Solution

I'm guessing that Defect Density is used in order to detect the rate at which your programmers are generating defects, whereas subtracting fixed defects is to do with the number of complaints made by your customers/end users.

Of your goals, (a) seems unsound, (b) is hugely incisive and will pay dividends and (c) may induce false optimism.

You should really be aiming for Zero Defects and you should, for metrics purposes, ignore bugs found and fixed before release.