Just so that this is noted, at least nowadays the description of the batterypatch package says that it overclocks the device. However, it's at the bottom of the description, where most users are unlikely to see it. (Sure we can say users should be more careful, and I'd agree, but even so something like an overclock should not automatically turn on without a clear affirmative from the end user.)

The other thing is if anyone goes and uploads a package that has batterypatch as a dependency, and that makes its way down to Extras or Extras-Testing, the dependency would be pulled with absolutely no warning or prompting to the user. So even if the description made it immediately obvious it overclocked, if it ever got pulled in as a dependency, users would not see its description unless they went out of their way to look.

[Insert other quotes about clear explanations of how the removal is determined.]
Agreed, a log and clearly stated guidelines for what is grounds for package removal would be nice. The log part might require some serious community coder volunteering to get that done in a way that doesn't depend on the people doing it manually updating the logs, though.

There's still choice, because you can always install the packages manually or out of extras-devel if you really want to choose that path. Yes it's a pain and extra inconvenience to either manually get the packages, or to enable extras-devel in the app managers and expose yourself to a bunch of other risks.

But think about this: a package is damaging, and gets promoted to Extras because enough people liked it without realizing that it is damaging, do the people who download it from Extras (expecting it to be safe) really choose to possibly mess up their systems? No, they just get messed up by a bad package that they might not have the skill or ability to check the safety of.

I take it you didn't notice I linked straight to this post in the initial post of this thread?

- Because users' choices should not be confined to only things other users can concieve of them wanting.
- Because the whole point of extras-devel is to have a hellish no-man's land where things can brick your device, but into which people can still venture to grab prebuilt packages if they so desire.
- Because one person's "is damaging" is another person's "risk I want to take", so while we might collectively agree something is too damaging for us to allow into the repos for unsuspecting users, we shouldn't deny those who /do/ want to take those risks the benefits of packages produced by an autobuilder instead of forcing them to go to precompiled binaries or build their own copies from source. Willingly taking a specific risk (downloading known broken package) does not mean willingness to take other risks (use precompiled binaries that are less guaranteed to match source than the autobuilt ones), or that they should be forced to choose between those other risks, or extra inconvenience (compiling from source). Yes I realize *patch packages are largely scripts, not binaries, but in general the above applies.
- Because it means one less repository to check (in case all repos have different versions) for the techstaff/volunteers/council/whoever.

Agreed. You'll note I didn't actually say "licence/debian packaging standards incompatibilities" along with damaging/harmful as reasons. I just listed that because it was one of the problems listed by sixwheeledbeast during the meeting.