BIP 50: Proposed action items, including the hardfork, are completed.
BIP 60: BIP 37 was apparently not clear on whether the new "relay transactions" flag was mandatory or optional. BIP 60 sought to explicitly make it mandatory. In parallel, Jeff Garzik interpreted BIP 37's field as mandatory in https://github.com/bitcoin/bitcoin/issues/2534 and Pieter Wuille implemented the changes required for that (and BIP 60) in https://github.com/bitcoin/bitcoin/pull/2763 . Numerous forks of Bitcoin Core since then have also picked up this change.
BIP 64: The getutxo message was implemented for use between (pre-contentious hardforks) Bitcoin XT and Lighthouse. Both of these are unmaintained now, but this does not seem relevant.
BIP 66: Softfork accepted by a supermajority of miners.
BIP 73: Implemented by at least Bitcoin Core and BitPay.
Previously BIP-0001 listed in its header preamble that is was a "Standards Track"
type proposal. This conflicts with both its own definition of "Standards Track"
proposal as well as the type listed in PEP-0001 of which BIP-0001 is based on.
Defitions of each type of proposal:
A Standards Track BIP describes any change that affects most or all Bitcoin implementations.
An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature.
A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process.
Specifically: "Any meta-BIP is also considered a Process BIP."
Based on these definitions BIP-0001 should have always been labeled as a "Process" BIP and this patch corrects this.
All of BIP62's (including the only-new-transactions) are currently enforced
as standardness rules, but it seems hard to push it further. Every new type
of complex transaction may require new extra rules, and some important types
of malleability cannot be addressed by it (for example, a single participant
in a multisig spend creating a new signature with a different nonce).
It seems wiser to pursue normalized txid or segregated witness-based
solutions, which do solve this problem more fundamentally.
