Logs:
Not relevant to issue

Steps to Reproduce:

1. Create a custom dragon breed using a datapack
2. Create a custom loot modifier that attempts to add the egg to an archaeology loot table, such as minecraft:archaeology/desert_well
3. Load up the datapack in-game. Run the /loot give @s loot minecraft:archaeology/desert_well command until you receive the egg you added. Observe the fact that the egg is dropped ALONGSIDE another item.
4. Travel to a desert biome and run the /place feature minecraft:desert_well command. Obtain a brush and brush any suspicious sand in the structure. You may want to repeat this a few times, but take notice of the fact that you NEVER receive the dragon egg you added to the loot table- a fact which was foreshadowed by the egg dropping alongside a different item in the previous step.

Description of issue:
When a dragon egg is added to any loot table, it appears to add it as a "bonus item" of sorts. For chest loot, this is of course not an issue, but for archaeology this means you can never obtain any dragon eggs placed into these loot tables without the use of the /loot command. So far, I've only tested with archaeology, but I assume other "single-drop" loot tables, namely most or all of the "gameplay" loot tables (cat gifts, fishing, Hero of the Village gifts, Piglin bartering, and Sniffer digging), would have the same issue

hmm.. this is actually kind of a dilemma, and less of a bug. Suspicious blocks (ones that can be brushed) are specifically hardcoded to ONLY ALLOW one item to come from the loot table. Which is understandable due to the nature of it (brushing out one item from the block only.)

The reason dragon eggs appear as "bonus items" is because they are essentially another loot pool added to the loot table, and is rolled whenever loot is queried to be generated.

Other situations where "single items" are expected actually do allow more than one item to drop, including cat gifts. If the loot table has more than one loot pool, anyway.

The problem here is some people may prefer the way it works now, as opposed to inserting the dragon egg into a loot pool; on the other hand, I also see why people may want to insert into a loot pool as opposed to having a whole new one.

Unfortunately, this seems to have been kind of an oversight on the design of Forge's Global Loot Modifier system, as there's no easy way to modify loot tables directly (like their pools etc.) only add to / change the outcome of the total loot amount.

A bandaid fix would be to replace the first item of the collection of items that are generated with an egg if the conditions are met, but I'm not quite happy with that. I have been looking for excuses to ditch forge-proprietary features for a while now, so this could be a opportunity to remove the biggest one in the mod...

I'll think on this.

I'm not particularly familiar with java coding, so I don't know if this would be doable, but maybe to handle the issue of people preferring how it works now, maybe you could add an additional field that, if specified, would make a dragon egg loot modifier replace an item in the loot table? Something like "override_items": true, and that way if a json file doesn't include "override_items" it defaults to false, keeping the current behavior, and then if that field is true, the first item in the collection could be replaced like you suggested
Alternatively, maybe there's some way to check what type of loot table you've been supplied in the loot modifier java code? Iirc the Alex's Caves mod was able to make a loot modifier type that works for both chests and archaeology, so there's probably some way to do it, but I wouldn't know how.

yeah alex's caves has a replace property that if true, just nukes the entire loot collection and replaces it with whatever the loot modifier says it to. Definitely not a fan of that approach, but I am leaning more towards implementing a insert_first property that if true, will forcibly replace the first item in the loot roll with the dragon egg. This effectively allows the retention of the original behavior and allows changing the "single pool tables" in areas that utilize it.

1.2.1 has been released introducing the replace_first feature. Enjoy!