The bug

Before 20w46a, when "type" was not specified, it would default to "minecraft:uniform", now it throws an error which breaks existing loot tables.

How to reproduce

1. Add this loot table to a data pack

   {
     "pools": [
       {
         "rolls": {
           "min": 1,
           "max": 4
         },
         "entries": []
       }
     ]
   }

2. Reload
3. You get the following error in the output log

   Couldn't parse loot table test:uniform
   com.google.gson.JsonSyntaxException: Missing type, expected to find a string
   	at afm.h(SourceFile:111)
   	at dbh$c.deserialize(SourceFile:76)
   	at com.google.gson.internal.bind.TreeTypeAdapter.read(TreeTypeAdapter.java:69)
   	at com.google.gson.Gson.fromJson(Gson.java:887)
   	at com.google.gson.Gson.fromJson(Gson.java:952)
   	...

Original description

Loot tables that have worked for a few major versions (1.12 and before) now are incompatible across the board (as far as I can tell...feel free to comment with any exceptions).

According to user BFSkinnyDipping on another similar but not quite the same bug report:

Datapack coder here, I'm having the same validation errors with the parser for loot tables compatible in 20w45a and prior but incompatible with 20w46a, and the issue seems to be that the "set_count" function expects an "add" parameter instead of defaulting to "false", which invalidates most datapack loot tabes. Is this intended behaviour or will this be looked at to allow for backwards compatibility?

Update: I'd like to correct myself! The problem isn't the "add" parameter, but rather that distributions require a specified "type" (like "type": "minecraft:uniform"), whilst previously this was only true for "set_count". In other words, "set_damage", "looting_enchant", etc. all have new requirements.

Nowhere in the changelog does it say that this was added. This took a long time to figure out and even longer to fix my packs.

So is 1.17 intended to be incompatible with everything that came before in datapack history? Or is this a bug?

EDIT: to be clear, the behavior I was expecting was that if the new fields were left out the game would assume the defaults were the intended values. The changelog for 20w46a listed perfectly sensible default values for the new fields.