ZDoom

Perhaps a new class, RandomGiver, could be made, which works similarly to RandomSpawner but only accepts Inventory-derived classes and can be given to the player? Most gameplay mods could pretty easily move to that.
If there's a mod that replaces health pick-ups with imps, well, that's a bit esoteric anyway and throwing an error message that "DoomImp is not an inventory item" in those cases to me seems more acceptable than every weapon replacement mod being broken in maps that use GiveInventory.

Several mods use RandomSpawners to replace original weapons.

I'm probably missing the forest for the trees, but how does RandomSpawner tie into this when it's not an item, so it has nothing to do with the ACS inventory functions?

No, it won't work well. All you need is a RandomSpawner and the whole thing will come down.

Can this be solved, then? It is pretty common to load a map-only mod with a gameplay mod, and this works fine for most scenarios including ZDoom maps because things are usually spawned into the map where they're affected by replacements. Some maps, however, decide to use GiveInventory either in tandem with ClearInventory to just give the player the Fist, or to give the player more stuff upon picking up an item placed in the map, and this causes problems.
I get that handling compatibility between two different mods might be a bit out of scope, so would it at least be possible to add an optional console warning when a script gives the player an item that would be replaced by a different one were it spawned in the map? That way it's not necessary to open up the map's script to see what the player should give themselves through console. It's not ideal – that would be something where the end user doesn't have to use console commands at all – and it would get annoying when handling a script that uses GiveInventory in a loop (dear god), but better than figuring out why map X doesn't give you Y weapons to use with all the ammo lying around.

[b]Edit:[/b] What about a new ZScript/DECORATE keyword that signifies "replace the thing I'm replacing even in inventory functions et al."? This would allow weapon replacement mods to work properly in the situations I've described without possibly breaking stuff by default. It might introduce other problems, but it would probably be far fewer cases than currently. It would also allow Smooth Doom to add back cards and skulls replacements – they used to be there, but because the original class names are checked for in custom scripts much more often, they had to be removed.

Replacements are only active for map spawns for good reasons - you cannot assume that the replacement for a weapon will do what the script code expects, so this was deliberately left out. Nothing here has changed.

Whenever the GiveInventory ACS function is used to give the player a vanilla weapon, it causes problems whenever using a mod that replaces weapons, because it doesn't check for replacing, so the player receives a weapon they can't select and use.
I don't know if modifying the original behaviour would be right (you never know what weird mod [i]relies[/i] on this, but I don't see how that would be a thing), so maybe a new ACS function that by default checks for replaces but can be told not to could work? Though that wouldn't help with all the pre-existing maps that would remain broken.