In general, almost all of this is out of scope for Launchpad itself.
* We did look into adding explicit database-modelled version information to bug tasks very early on in the design, but it was ruled excessively complicated and it's unlikely that we'll add it at this point.
* While I certainly agree that data destruction is important, determining this and managing bug importances is up to the maintainers of the project/package in question.
* Some bugs have workarounds, but many don't, and can only be addressed by upgrading or similar - no matter how much we might wish it to be otherwise. Project maintainers can and do edit bug descriptions to add workaround information at times, which I think is wiser than adding a new "correction" field. We don't have to have explicit fields for every possibility, and adding that would become unmanageable; Launchpad's bug tracking system is already complex.
* Dealing with manufacturers is clearly not something that Launchpad (as a hosting site) can do.
In general, almost all of this is out of scope for Launchpad itself.
* We did look into adding explicit database-modelled version information to bug tasks very early on in the design, but it was ruled excessively complicated and it's unlikely that we'll add it at this point.
* While I certainly agree that data destruction is important, determining this and managing bug importances is up to the maintainers of the project/package in question.
* Some bugs have workarounds, but many don't, and can only be addressed by upgrading or similar - no matter how much we might wish it to be otherwise. Project maintainers can and do edit bug descriptions to add workaround information at times, which I think is wiser than adding a new "correction" field. We don't have to have explicit fields for every possibility, and adding that would become unmanageable; Launchpad's bug tracking system is already complex.
* Dealing with manufacturers is clearly not something that Launchpad (as a hosting site) can do.