I really don't see why we have any need to make this a throw, that only makes sense if there's no equivalent package, and that would be element. tbh, all aliases should be like a lib.warn guiding people to use the new option like in mkRenamedOptionModule. Plus, these lists are not being reliably cleaned up before release.

I'm inclined to say we shouldn't change anything.

@worldofpeace I'd like to avoid confusion by people who mistake riot with element. And in this case, it can be mostly fixed by a single s/riot/element/g. The entire application has been rebranded and some feature-flags were removed as those are available by default.

Plus, these lists are not being reliably cleaned up before release.

I'm well-aware that the current situation isn't perfect. However those aliases are usually prefixed with a comment mentioning the release where those can be dropped, so at least that's documented an no-one has to e.g. check all aliases in question manually.

For 20.03, I would say a warn is enough. It leaves the possibility open to postpone (manual) configuration changes until 20.09. It should be only s/riot/element/g but you never know.
For 20.09 the riot-* options should be removed completely.

For 20.03, I would say a warn is enough.

I believe using lib.warn here breaks evaluation. Might have to check the tracker for the previous case of that.

It does, that's why I didn't do it for now.

@worldofpeace I'd like to avoid confusion by people who mistake riot with element. And in this case, it can be mostly fixed by a single s/riot/element/g. The entire application has been rebranded and some feature-flags were removed as those are available by default.

Interesting, I guess you could say a rebrand of an application that includes a name change is just on the fence of being a new application and not being a new application (where silently not being aware of the attribute change doesn't make sense). And I can see that, since lib.warn isn't an option (IIRC), throw is the next best thing.
With that explanation I can see why this is now needed 👍 Perhaps expand the commit message slightly to make it more evident? (if you feel like it 😁 ).

I updated the commit message and also referenced the discussion here.

@worldofpeace I've seen today that you also mentioned this issue in rfc#33. As I regularly take care of processes like this (and also do nixpkgs maintenance for a while now), I'd be happy to support establishing an improved deprecation process. Feel free to ping me in the relevant discussions if you think I might be helpful for that :)

Approved by two contributors now and we came to the conclusion that the usage of a throw is currently the best option here, so I'll merge now.