Unstable Book Updates needed

[ZerothLaw]

Mostly listing parts of the book that need work, need tracking updates, etc.

• abi_x86_interrupt - Unlikely to ever be stabilized, could probably move the documentation from the tracking issue to the book
• allow_fail - link doesn't go to a tracking issue but the initial PR that added the feature
• bind_by_move_pattern_guards - obsoleted by NLL work, will probably be closed soon
• cfg _target_thread_local - links to the same tracking issue as thread_local does, which is confusing.
• cfg_target_vendor - been unstable for nearly four years now, no listed reason in the tracking issue for why it is still unstable
• crate_visibility_modifier - links to a now-closed tracking issue
• custom_derive - links to a now-closed tracking issue
• doc_alias - could be stabilized?
• exhaustive_integer_patterns - has been stabilized
• existential_type - mismatch between name of feature, and the name of the tracking issue. Perhaps incorrect tracking issue?

Taking a break, will add more later.

[Centril]

• bind_by_move_pattern_guards -- tracked by #15287
• crate_visibility_modifier -- new issue is #53120
• custom_derive -- removed from language by #54271

[mark-i-m]

I think we need to rethink the unstable book altogether. Every time I have gone to it, it has been... unhelpful. Usually, I just end up reading the tracking issue anyway. Perhaps what we want instead is an automatically generated index of features... something like a table a like this:

feature	tracking issue	status
asm	#29722	implemented, but buggy

Though maybe the status is better left to the tracking issue unless we can find a way to update it automatically...

[ZerothLaw]

Yeah, that seems to be the issue in the ones I looked at. If we think of it as source code, the Unstable book depends on those tracking issues. But because there's no checking of the tracking issues, the source code becomes outdated and defective.

[steveklabnik]

@mark-i-m i have also felt like the unstable book is not meeting its goals. I would be open to the idea of a single page, with the feature names and tracking issues.

Furthermore, the unstable book was made a book with the idea that it could be where documentation lands before the feature does, but given the new changes to the rfc process that @nikomatsakis and others have been talking about, if those changes go through, there will be a new place for them to live, de-ephasizing the "book" nature of the unstable book all together.

[mark-i-m]

I’m curious if you think that should be done as part of broader RFC reform or as its own measure?

[mark-i-m]

Specifically, I think that any successful process reforms will need to include heavy automation to scale well.