SinisterRectus

I already said I didn't want to change this. 1 and 3 are intentional. 2 is fine.

This looks great except I would prefer to use the API term "flag" everywhere instead of using the product term "badge". So, `user:hasFlag` instead of `user:hasBadge` and `user.flags` instead of...

I'm not sure I like the `user.badges` or `user.flags` property, but it's probably the best we can do. For permissions, we have a dedicated class so that `member:getPermissions():toArray()` gives the...

Numbers were used when signals were [added](https://github.com/luvit/luvit/commit/b9b569eb453c8d13b7999d001678e247a9fa906e) to an old luvit version. After luv was split into its own project, signals were [reintroduced](https://github.com/luvit/luv/commit/75730c68d772d8aa2da551c2fbabbc1d6a015e0) using uppercase strings. This implementation was eventually...

Changing to `signame` is good, though I would recommend `sigstr` or `sigstring` if either of those provide any extra assurance that the value is e.g. `"sigint"` instead of `"SIGINT"`. We...

Adding the new parameters is also fine, if that helps things. The order difference is indeed unfortunate, though.

With #713, we now have documented the behavior encountered in this issue. As you can see by this change, there are places other than signals where the library optionally accepts...

Is it enough to just make the url conditional then?

Sounds good, except I'm too lazy to write logic for semver comparisons in languages that I don't know. I'll change this to a draft for now.

Alternatively, the script can fallback to the old url format if the new one fails.