The "data" in "append_static" of "block_entity_modifier" in "rule" processor and biome item particle effect's "tag" don't work as expected

Can confirm it does not work with any block entity.

After much trial and error, I found that it does work, you just have to write the NBT as JSON. So in your example, do

"output_nbt": {
  "Lock": "something"
}

I'm not sure whether that is intended

Either way, it is inconsistent with everywhere else where you provide NBT in JSON.

Found one other place that writes NBT this way:

Biome file > effects > particle > options > value > tag (when particle is minecraft:item)

Can confirm in 1.18.1.
Suggesting the report be rewritten to something similar to this:

Title: Processor type rule's "output_nbt" and biome item particle effect's "tag" don't work as expected

Description:
In processor lists, entries with processor type "rule" have a property named "output_nbt".
In a biome json file, the particle effect if set to "item" has a "tag" property under options, value.

Both of these properties request NBT to be specified, but the conventional way of specifying nbt in json files doesn't work. The NBT is instead in a different format from every other file.

"{some_nbt_tag:1b}"

The format that does work is below this line, this prevents providing data type suffixes and makes lists, which would be invalid NBT, valid syntax for JSON.

{"some_nbt_tag":1,"not_valid_nbt_list":["hey",{"this_is":"seemingly allowed"}]}

These instances should be changed to require the string input, rather than this weird method, then it's also consistent with advancements, loot tables, predicates, etc.

Can confirm in 1.20.1.
Suggesting the report be rewritten like below to match current versions and add more info:

Title: The "data" in "append_static" of "block_entity_modifier" in "rule" processor and biome item particle effect's "tag" don't work as expected

Description:

In processor lists, entries with processor type "rule" have a property named "block_entity_modifier", which has a type "append_static" with a tag "data".
In a biome json file, the particle effect if set to "item" has a "tag" property under options, value.

Both of these properties request NBT to be specified, but the conventional way of specifying nbt in json files doesn't work. Unlike every other file, which requires SNBT:

"{some_nbt_tag:1b}"

The NBT is instead required to be specified in a JsonObject like the example below this line. This prevents providing data type suffixes and makes lists, which would be invalid NBT, valid syntax for JSON.

{"some_nbt_tag":1,"not_valid_nbt_list":["hey",{"this_is":"seemingly allowed"}]}

More importantly, some NBT cannot be provided in this format. For example, an NBT with an integer array to merge into a chest:

{Items:[{Slot:0b,id:"firework_rocket",Count:1b,tag:{Fireworks:{Explosions:[{Colors:[I;16711680,65280,255]}]}}}]}

When using:

{"Items":[{"Slot":0,"id":"firework_rocket","Count":1,"tag":{"Fireworks":{"Explosions":[{"Colors":[16711680,65280,255]}]}}}]}

The game will convert this JsonObject to an NBT like:

{Items:[{Slot:0b,id:"firework_rocket",Count:1b,tag:{Fireworks:{Explosions:[{Colors:[{"":16711680},{"":65280},{"":255s}]}]}}}]}

which is not correct. This example can be reproduced with the attached data pack, using command /place structure test:test_structure

Theoretically, conversion JsonObject into NBT is unfeasible at all. Here is also some information about conversion between Json to NBT.

These two instances should be changed to require the string input, rather than this weird method, then it's also consistent with advancements, loot tables, predicates, etc.