The Problem

It's hard to change the "type" of a colored block. e.g. from all *_wool to *_concrete. It's also not possible to easily "wax" all copper blocks.

A Solution

Since all of the above problems are based on structural replacement of the type string, a nice generic solution is to allow substitution on the type string itself. For example, s/_wool/_concrete could be our pattern syntax to do the aforementioned wool -> concrete swap. It would be used as //set s/_wool/_concrete.

The copper example is a little more complicated due to the naming of it: s/^(cut_)?copper/waxed_$1copper/, to turn any normal copper block into a waxed variant.

Alternatives

Split out dedicated patterns or commands for this. The problem with this is that we'd need to maintain the exact mapping, and it wouldn't allow other flexible replacements.

Anything Else?

No response

Another interesting use would be to replace all blocks in a family with another family, such as birch_* to acacia_*.

The example of waxing blocks isn't entirely complete since signs can be waxed as well. If the situation isn't too niche, would having a command to wax both copper and signs be desired?

The primary reason we are pushing most of this into "the user should do it" is for mod compatibility. Historically trying to maintain specific lists for things has made it confusing and difficult when mods don't work with commands that say things like "wax any block". Or if a mod adds a new type of sign, it wouldn't get waxed by that command. So unless there is a really big need for it and it can't be solved by just copying a regex from our docs, or keeping a local note of the ones you need, I think we'd rather not add any commands that don't work on a generic property given in code. There is actually a waxing map inside vanilla code, but it doesn't look like any modding API hooks into it, so it would still be confusing.

The waxable map can be registered to with Fabric API at least.

Hmm, that may be do-able then, as we would simply request that Forge, etc. implement a similar API.

For waxing, signs would have to be hardcoded since their waxing is part of the block entity and not block state. Would you consider that alright since waxing should apply to all signs extending the vanilla class?

There's a few other block transformations like flattening, oxidizing and deoxidizing, stripping, and tilling, but I think their usefulness would be limited. Tilling would probably cause trouble as it uses a consumer rather than a simple block-to-block map. Waxing could also include the inverse operation which would be unwaxing or scraping the block. What do you think?