Explorer.exe hasn't been "the shell" in a few versions of Windows now, and never as directly in any of the Windows NT family (XP+) like it was to Windows 95 [1]. For instance, the taskbar and start menu have moved into an application that Taskbar calls the "Windows Shell Experience Host".

But the big issue here is not just making the Shell replaceable, and not even just replaceable at runtime (switching/reconfiguring Shells on the fly; which was not something that was possible even in the Windows 95 INI days), but also presumably a lot more about the Windows build and deployment infrastructure. Up to this point the Shells are built together with the rest of Windows, baked into the Windows image, and deployed together as a single versioned unit (one build of Windows). Sure maybe it is just an "unsexy" "refactoring" of existing components to be more component like, and try to minimize coupling between specific versions of them, but my DevOps hat certainly thinks it sounds like a lot of work for a codebase as old and large as Windows.

[1] Windows 95 did use Explorer.exe for just about everything, and many people do remember that for compatibility reasons it supported changing the "Shell" EXE in an INI file, and you could change it into the Ghost of Windows 3.1 PROGMAN.EXE or some alternatives shells supported that. That INI has never been in the Windows NT side of the family (XP+).

If you mean MinWin, they did not only attempt it, it powers Windows Core.

They attempted to do it as far back as Windows NT, which was originally supposed to support multiple shells, including OS/2.