In your description, you mention that this is a “minimal interface”. I’d argue that neither flashFeeToken or availableForFlashLoan are actually required for a truly minimal interface.
The lending contract can simply revert if the correct fee hasn’t been paid, and can similarly revert if a particular token isn’t available for loaning.
Granted these functions make it more pleasant to work with, so maybe the correct solution is to change the description field 
flashFeeToken seems too limiting. If you want to support paying fees with multiple different tokens, you’d need to deploy several different ERC-6682 contracts, right?
I think you could go with a more flexible interface, replacing flashFeeToken and availableForFlashLoan with:
function flashFee(address token, uint256 tokenId, address feeToken) public view returns (uint256);
where token is the NFT contract, tokenId is the NFT’s id, and feeToken is the token the borrower wants to pay with. Then flashFee would return the fee denominated in feeToken required to borrow that NFT, or revert if that NFT isn’t available or that fee token isn’t supported.
I’m not sure how valuable it is to reuse the ERC-3156 interface here. It seems like they are different enough to just make your own interface instead of extending it. Like amount makes no sense for ERC-721 tokens.
I’m not super versed in the NFT world, so I might be way off here, but this interface doesn’t seem like it would handle special properties of the NFT. For example, if the lender is the NFT contract itself, it might be willing to mint/loan/burn the tokens on the fly, and not require the tokens exist beforehand. If that is the case, the borrower might want to specify properties (for an art NFT a “special property” might be background colour; for an ENS-like token, it might be the domain name.) This interface doesn’t allow the borrower to specify those properties.