To quote the docs:
true if dropping values of type
I'm reading this as "returns whether it is possible for code to observe a difference between
mem::forget(x)". So, yes, an aggressively-optimizing rustc could choose to make a
T: Drop type have
false, if it can deduce that calling the destructor cannot be observed. If this reading is incorrect, we have a documentation bug.
My rationale for a resistance to adding a non-unwinding functions comes down to "noexcept is a massive pain in C++", as evidenced by the piles and piles of noexcept overloads in the STL; Java's throws is also a pretty good example. I am not a fan of exceptional control flow, and I don't think we should make the mistake of making panics part of the type system. I'm sorry for not being explicit about that.
I'm not sure why you think this is a corollary of such a feature. I suspect the confusion here is that, much like how you believe
T: Drop must imply
needs_drop (something the documentation does not promise), you believe that having
!can_panic_unwind(f) must imply that
f: #[nounwind] fn() must typecheck.
In a world where the information tracked by Column A and Column B is the same, literal value in a compiler data structure, then yes, such implications hold, but such an implementation restriction should never be specified, because it restricts compilers willing to put in more AOT work to prove stronger statements about the programs they are compiling, so to further optimize that program.
I'll leave with an elaboration of my devirtualization example: suppose you have some sealed (sealed with the usual privacy tricks) trait
T. For sealed traits, the compiler knows the total implementations of
T, and can, ostensibly, determine that no implementor of
T requires drop glue; hence,
needs_drop::<dyn T>() could return false and be within the parameters specified by documentation (since it is not possible to observe the destructor not being run: all the potential dtors in the vtable are no-ops). This is kind of a dumb niche optimization, but an example of why you might want this (though your example of a dtor that is a pure function is also pretty solid).
 Ok, yes,
needs_drop requires the type to be
Sized. For sake of argument, assume that it does not have this implicit bound.
In any case, this argument does not feel productive. I have made my point, you disagree, I have given you my rebuttal, and I'm going to let other people decide if they think it's you or I who is in the right.