Although I can not say whether the specific API proposed here is useful or not (matz may just
have to decide on the API for general use), I agree with the statement of controlling/toggling
the "noise" level, based on different needs by the ruby user - some prefer warnings, which is
fine, whereas others may prefer less warnings (or just suppress some warnings specifically
while allowing others to show up).
I do not have an alternative API proposal, but the suggestions here make sense to me.
I think :deprecated and :pattern_matching is simple to understand; for :experimental, it may
have to be defined clearly what exactly is to be considered experimental and what is not, since
this may change between ruby versions.
Perhaps there should be some way to query from ruby which specific features are experimental
or not, e. g. an Array of symbols or something like that. That way the ruby user can make
conditional checks and enable/disable certain features selectively (or not), or rather the
warnings for such experimental features, on a per gem/project basis too - but I digress.
In short I think the suggestion by znz makes sense.
Updated by 
Updated by 
Updated by