my impressions, mostly to start a wider discussion about this:
CIP 27 … has not really been adopted by the community
A workable CIP submission would have to go into more detail about this: at least quoting a source, and perhaps citing a reference implementation if there was one (e.g. a CIP-27 implementation which the community didn’t adopt).
And mainly… if this could be written so it’s backwards-compatible with CIP-27 (offhand I don’t see why applications couldn’t check "rate" to see whether it’s an array) that would help it get through the CIP process, considering how many agencies were backing CIP-27 as it was written (from Abstract):
It has been developed with input from Artano, BuffyBot, CNFT.io, Digital Syndicate, Fencemaker, MADinArt, NFT-Maker.io, Hydrun, Tokhun, and many more.
At some point all these stakeholders agreed that the proper way to more finely distribute royalties was with a smart contract & it’s likely they considered this approach already. I would be interested in bringing them into the discussion to document more about why they didn’t write it that way from the beginning (and would they do it any differently now?).
The rest is beyond me since I’m not an NFT expert. The one thing I would be sure of is that the addition of Royalty reference token standard (776) doesn’t make it possible to change the royalty rules after a token is released… the consortium that developed CIP-27 seemed pretty emphatic about that, which to me makes common sense.
Copying the main participants of prior forum thread - CIP - Royalties (I would want to do the same with contributors to PR#116 if & when you make a pull request on GitHub): @Huth_S0lo @DeFi_Authority