It uses Hexen format levels:

P_SetupLevel: E1M1: Hexen format not supported
R_FlatNumForName: CJLOGO1 not found
R_FlatNumForName: CARPET_A not found
Segmentation fault (core dumped)

The download comes with its own version of ZDoom and aparently it's a custom one, with custom additional pk3. Below a quote from Graf Zahl (author of GZDoom):

I have to admit that I'm a bit disappointed by the way this mod has been created. Instead of actually using ZDoom's features to create custom content all the changes were made to the internal definitions in ZDoom.pk3, making it a major hassle to add proper support for it, or play it with GZDoom's GL renderer.

It's neither compatible to Doom.wad's nor Chex.wad's definitions.

And they made some source modifications but the only source link I could find was for an unchanged GZDoom 1.1.3 version which is clearly not what is in the download version.

Maybe we could get it to run at some point. But even when running it on GZDoom it has some graphical glitches.

I don't know when it happened, but ZDoom/GZDoom/Zandronum/Skulltag(?) have had native support for the chex quest 3 iwad for a long time now. Granted, there's no advantage to porting the custom version of ZDoom used for chex quest 3's initial release except for demo playback support... Also, I personally recommend that before going for something as complex as the ZDoom family, we get libretro ports of Chocolate Doom (with Crispy Doom's 60fps interpolation hardcoded on for demo compatibility), Crispy Doom and PrBoom-Plus (to replace or supplement the current prboom core.

@Danfun64 I'm not saying they don't support it at all, it runs but it's glitchy.
Just look around the first room in chex quest 3 and you'll see some objects have a weird animation in which they switch completely their sprite, as if they were alternating between different objects. This is because the animations were hardcoded in the engine modification instead of defining them properly within the IWAD.

Support for loading the Hexen maps could be added without full ZDoom support, or even ACS. This change on prboom-plus is a first step on that: coelckers/prboom-plus#12
You can load the chex 3 map with that change, but the linedef specials won't work so you won't be able to open doors and interact with buttons, some conversion of the specials needs to be done.

Note that this core already does 60fps interpolation and can play demos. I'm not sure if porting Crispy would make it much different, since a libretro core cannot depend on timers if it wants to integrate with the libretro API for controlling the game speed.

I think if there's to be a new core it should be one that has support for Heretic/Hexen/Strife, and preferably one that's still maintained upstream. Maybe k8vavoom is a good candidate. Or the eternity engine, which is possibly the most modern prboom-based port (it has UDMF support, portals, and there's a significant level of support for Heretic, Hexen and Strife).

After all, for true vanilla gameplay you can already use the DOSBox core with the original engine, so porting something like Chocolate Doom might not be that useful. Perhaps it'd run better than prboom on low-end platforms, but I think prboom already runs pretty decently on the lower settings and can load more community wads than most chocolate-based ports.

You're gonna have to be more specific with "the first room". Do you mean in the first episode or the third episode? Also what version of GZDoom are you running for this?

Chex Quest 3 is dependent on Decorate, so even if you get ACS and Hexen support added, it still wouldn't support the game 100%.

The PrBoom core changes the speed of the game, resulting in demo desync. Granted, it doesn't feel that different in gameplay, but look at DEMO1 of doom 2. The player is supposed to die at the end, but somehow survives and then just stands there. Even if that wasn't a problem, PrBoom (not plus) has deliberate changes in physics for the vanilla complevels to make it obvious that demos were recorded through them (PrBoom-Plus reverses these changes).

What exactly do you mean by "cannot depend on timers"?

The problem with converting ports like k8vavoom, eternity, and GZDoom to Libretro is that they're moving targets. A refactor could end up turning a bunch of work for naught. Similarly, save states taken with them are not guaranteed to be compatible with newer versions. I know for other systems, like MAME and Snes9x, there are multiple versions available as cores... but at least for those, it's working with something finalized and stable enough to make into cores.

The reason I chose Chocolate Doom as a core to implement is that it's stable by its very nature. It aims for a specific target and tries to be compatible with it to the best of its ability. Not to mention its Heretic and Hexen support. Crispy Doom (which is a fork of Chocolate Doom as you probably know) implements interpolation in a way that doesn't change the game's speed.

No offense, but I was never really fond of libretro cores that solely emulate computers that rely entirely on keyboards. It interferes with retroarch functionality (I think there's a button which disables most of retroarch's hotkeys, but I don't remember what it is). Besides, the main reason to run Doom on Retroarch would be for controller support, something which the dosbox core would be poor at.

The only disadvantage to replacing the PrBoom core with a port of PrBoom-Plus would be that PrBoom-Plus's netcode is completely shot, but I don't think Retroarch ever supported PrBoom's multiplayer capabilities, and that's one thing Chocolate Doom can be used for.

As for the more advanced ports, k8vavoom is even less "stable" than GZDoom at the moment, so I don't recommend its use as a libretro port at this time.

The Eternity Engine actually isn't based off the PrBoom-Plus linege. It goes like this:

Linux Doom -> DosDoom -> Boom -> Marine's Best Friend -> Smack My Marine Up -> Eternity.

PrBoom-Plus only goes up to MBF...but that's simplifying the picture.

There's a fork of Eternity that adds 4 player split screen support, but it predates a major SDL2 refactor so I'm not sure I can recommend it for porting purposes.

From both a stability and future proofing standpoint, I still think Chocolate Doom, Crispy Doom, and PrBoom-Plus should be the first priorities for libretro porting. Only after you get those more conservative ports in should you focus on the more advanced stuff.

I meant the very first sector of the first map in the first episode of chex 3.
But I've downloaded the newest GZDoom now and it's actually not happening anymore, they might have added explicit support for it.

Desyncs with vanilla demos most likely are bugs in the changes done when porting it to libretro. Does original prboom have those desyncs? if that's the case and prboom-plus committed fixes for those then maybe they can be backported. But I'd be surprised if original prboom had desyncs with official demos since it was meant to be able to emulate vanilla behavior and it introduced compatibility flags for that.
When prboom was ported a lot of stuff was stripped out, for porting prboom-plus it's likely even more stuff would have to be stripped out, it might end up not being that different, perhaps it'd even have the same problems you mention about "speed", since that's most likely due to the core implementation.

By "cannot depend on timers" I meant that libretro controls the game speed by controlling the game loop. Most engines, like prboom or crispy use timers to know when a 1/35 of a second has passed and a game tic can run. In the libretro core, instead of using timers it relies on knowing the fixed FPS that it should run on, it'll take a certain number of frames to run a game tic. So for example if the game runs at 140 FPS, then there will be a game tic every 4 frames (140/35 = 4). The game will run slower if your computer is not fast enough to reach 140 real FPS but you configured for 140 FPS.
However, this in theory should not affect demo compatibility, since demos only record the game tics and it would not matter how long you take to execute a tic, even if the movement was slower the entire game would be proportionally slower too. Unless there's a bug somewhere.

If you want to port Chocolate Doom, please do go ahead, do not let me stop you from doing it.
If Chocolate Heretic and Chocolate Hexen can be ported too that'd be awesome. Though in Chocolate they are separately built ports which might be kind of messy because you'd need to use the right core for the right wad. Personally I'd prefer a single installed core that could load all Doom engine wads.

I know Eternity is not really direct descendant of prboom, but it's the closest relative in modern ports, sort of a cousin (both are MBF descendants) which has also taken a lot of things from prboom, one of the objectives of Eternity is to be able to replace PrBoom and yet have modern features.

About stability, it wouldn't be the first in-progress libretro core (openlara for example was barely playable when it was first ported). Imho if the core can be upstreamed it might even be a good thing to do it when it's young sicne it'd be easier to port it and future development upstream can take the libretro port into account as it develops further.
But I guess ultimately it depends on the person who decides to make the port.

Can confirm that in vanilla PrBoom, Doomguy dies where he is supposed to in doom2.wad DEMO01