You are right and so to ensure maximal backward compatibility and minimalism of the interface, I’ve decided to rename Bond and boundTo to Transfer and ownerOf.
From my understanding of Solidity and its surrounding standards, specifically ERC165: It was exactly built for this type of feature detection functionality. I’ve now specifically mentioned it in the standard’s “Rationale” section, but essentially a properly built ERC721 wallet should already be able to detect when a token isn’t transferrable when e.g. the ERC165 identifier 0x80ac58cd for its transfer function isn’t supported.
As you’re suggesting, having wallets to make an extra asynchronous call is the wrong path in my opinion. Not only may this lead to an immense amount of requests NFT metadata hosts, but it would also ignore the existence and purpose of ERC165.
The reason why in my opinion a new but minimal standards interface is mandatory is that e.g. just reverting on transfers of an ERC721 token is also bad. While e.g. a machine or wallet can indeed detect features using ERC165’s supportsInterface function, it cannot interpret whether an ERC721 token’s transfer function fails (e.g. "does it fail because the token is soulbound or e.g. does it fail because of faulty input parameters).
Since, however, event Transfer and function ownerOf are a part of ERC721’s track and transfer interface, but so is function transfer, we’ll have to cut this functionality and reintroduce it as a new interface.
For the future, maybe we can have a non-fungible token with entirely composable ownership properties (e.g. private property, Harberger property, or soulbound property). However, for now this is not the scope of the standard.