Considering a roadmap for 1.0, or alternatively considering deprecating in favor of the "globset" crate

Per the original rust-lang-nursery RFC ( https://github.com/rust-lang/rfcs/blob/master/text/1242-rust-lang-crates.md ):

If the library team accepts a crate into the nursery, they are indicating an interest in ultimately advertising the crate as "a core part of Rust", and in maintaining the crate permanently. During the 0.X series in the nursery, the original crate author maintains control of the crate, approving PRs and so on, but the library subteam and broader community is expected to participate.
Eventually, a nursery crate will either fail (and move to rust-lang-deprecated) or reach a point where a 1.0 release would be appropriate.
If, on the other hand, a library reaches the 1.0 point, it is ready to be promoted into rust-lang proper. To do so, an RFC must be written outlining the motivation for the crate, the reasons that community ownership are important, and delving into the API design and its rationale design.

I'm not sure who the "original crate author" of glob is, as I'm guessing this crate was split out from the stdlib during the great pre-1.0 purge, but it doesn't appear that there's any real champion trying to advance this crate through the stabilization process.

I'm interested in starting a discussion as to the future of this crate. Sadly I can't find the original petition arguing why this crate belongs in the nursery in the first place, so I'm not even sure how to begin evaluating the aspirations of this crate that keep it from being 1.0 today.

Let's focus on answering three concrete questions:

1. Does glob matching deserve to be "a core part of Rust", per RFC 1242? If not, then this repository should be moved to rust-lang-deprecated. But if so, then:
2. Is this implementation of glob matching superior to other existing solutions that could be promoted to "official" crates (in particular, globset ( https://crates.io/crates/globset ) appears to be promising). If not, we should deprecate glob and consider promoting the alternative solution to rust-lang-nursery. But if so, then:
3. Does anyone care enough about this crate to push it over the finish line? If so, then they should produce a prospective 1.0 RFC. But if not, then I think it sets a bad precedent to allow a crate to languish in the nursery forever, and this crate should be deprecated until such time as it finds a champion.

I don't consider myself an expert in either crate, but the biggest potential pitfall that I see when comparing glob to globset is that the latter relies on the complete regex crate, and transitively all of regex's dependencies. In contrast, glob is small self-contained, but appears to be less featureful than globset, and I'm unsure if it handles both Unicode and non-Unicode as well as the regex crate. Some microbenchmarks would be interesting to see as well.

Tagging @burntsushi, as the author of globset and who's familiar with the rust-lang-nursery process. And tagging @alexcrichton, who I'm guessing doesn't particularly care about this crate but who's the only active point of contact listed for this crate on crates.io. :P

Start by reviewing RFC 1242 and the existing glob and globset crates, focusing on their feature sets, Unicode and non-Unicode handling, dependencies, and performance. Compare whether glob merits a 1.0 path and identify a champion; done means producing a prospective 1.0 RFC or documenting the case for deprecation.