Issue 1:
This is meant as a meta-bug for me to collect references to places where users complained about fallout from Sound Generic Drop (#21972) and its precursors (namely #21657 in particular).

It might be a places to pose ideas for ways to address complaints, but keeping in mind the distinction between language features versus tooling, I would prefer for the comments on this ticket to focus on things we can do without changing the language per se, and try to put language changes somewhere on the RFC repo. For example, ways to encode "this destructor for this type is pure" is an example of such a language feature.

(I do not know where something like "borrow scopes should not always be lexical" (#6393) falls in that categorization; that might be an example of something that would not require an RFC, but maybe it does at this point.)

Potential work items:

Make Vec<T>, Box<T>, Rc<T>, etc, covariant with respect to T. Discussed on issue #21198 (was not a strict requirement for landing new destructor semantics).

Track even finer grained scopes, e.g. destruction order of temporary rvalues in an expression. Issue #22323

fixed by non-lexical lifetimes (NLL), so @pnkfelix is choosing to check off its box here.

Implement refined Drop check rule that respects the side-condition "where T is a trait that has at least one method item" #24805

uses of terms "superregion" and "subregion" suboptimal #22171

new scoping rules for safe dtors can yield spurious semi-colon or trailing unit expr #21114

Temporary lifetimes sometimes yield surprising errors #46413

(Note that with non-lexical lifetimes (NLL) enabled, #46413 is effectively a duplicate of #21114.)

key terms: destruction scope, block suffix, unsafe_destructor

Issue 2:
I'm using libcore and liballoc to build a freestanding kernel, and it used to work perfectly on 1.0.0-nightly (2b01a37 2015-02-21).

But since I updated my Rust and my rust submodule (including any dependencies) to the latest 1.0.0-nightly (c89de2c 2015-03-28), I get a whole slew of these errors when building liballoc or anything that depends on it:

Compiling alloc v0.0.1 (file:///home/virtlink/projects/alloctest/lib/liballoc)
src/lib.rs:1:1: 1:1 error: duplicate entry for `const_ptr` [E0152]
src/lib.rs:1 // Copyright 2014 The Rust Project Developers. See the COPYRIGHT
^
src/lib.rs:1:1: 1:1 error: duplicate entry for `mut_ptr` [E0152]
src/lib.rs:1 // Copyright 2014 The Rust Project Developers. See the COPYRIGHT
^
src/lib.rs:1:1: 1:1 error: duplicate entry for `i8` [E0152]
src/lib.rs:1 // Copyright 2014 The Rust Project Developers. See the COPYRIGHT

...

src/lib.rs:1:1: 1:1 error: duplicate entry for `non_zero` [E0152]
src/lib.rs:1 // Copyright 2014 The Rust Project Developers. See the COPYRIGHT
^
src/lib.rs:1:1: 1:1 error: duplicate entry for `debug_trait` [E0152]
src/lib.rs:1 // Copyright 2014 The Rust Project Developers. See the COPYRIGHT
^
error: aborting due to 58 previous errors
Could not compile `alloc`.

I symlink libcore and liballoc, and add a Cargo.toml for each (see below). Here's a working reproduction of the issue:

cargo new alloctest
cd alloctest
mkdir -p lib/libcore
mkdir -p lib/liballoc

git submodule add https://github.com/rust-lang/rust.git lib/rust
cd lib/rust
git checkout c89de2c56baeb61e7cc434924dcc8bedd32b26b8

cd ../libcore
ln -s ../rust/src/libcore/ src

cat << EOF > Cargo.toml
[package]
name = "core"
version = "0.0.1"
authors = [ "some@example.com" ]
EOF

cd ../liballoc
ln -s ../rust/src/liballoc/ src

cat << EOF > Cargo.toml
[package]
name = "alloc"
version = "0.0.1"
authors = [ "some@example.com" ]

[features]
external_funcs = []

[dependencies.core]
path = "../libcore"
EOF

cargo build