I'm not aware of a chip that combines the two onto a single die like that, or a shared address space but I'm sure someone has made a multi-chip module with both topologies on-board.
To address your comment about NAND boot areas, they are special only because some NAND chips are sold with guaranteed 'good' sectors at the start, where you can store infrequently updated code such as a bootloader or other IPL. This saves you from having to juggle that critical piece of software around during normal NAND controller operations that may re-map bad blocks, etc.
I suppose someone who implemented their own memory controller in a FPGA and connected two separate parallel memories, one NAND and one NOR could implement such a device, but that's a lot of hardware.
It's unclear why reading address 0x1FF8007C does not work, I get the same failure.
However, experimenting with a Nucleo-L073RZ shows that it will permit one to read 128 bytes starting at address 0x1FF80000, which will have the flash size value which you seek as its penultimate 16-bit word.
Thinking it might be an offset issue I tried reads at 0x1FF80000 + [0x70, 0x60, 0x40] none of which worked. Conversely, reading at 0x800007c does work, so offsets are allowed in general. And as the read size is sent after the point where the address is NAK'd, it's not an issue with a 32- or 16-bit read being required.
Anyway, reading out a 128 byte block should solve your problem.
Another idea would be to start at an address near the top of the largest flash size and read down until you stop getting a failure. Or you could load a little stub into RAM and execute it. But it seems like reading out 128 bytes will be your simplest solution.
As an aside, using https://github.com/florisla/stm32loader (which seems to be what is on pypi, you didn't say what you were using) I found that I had to reset the chip each time I invoked the program, so apparently it is not leaving the bootloader in the right state. Still, that is an improvement over another tool I'd tried a few months back, which refused to talk to the L07x bootloader at all, though it was fine with the L05x one...
If one really wanted to spend an afternoon descending a rabbit hole, it would probably be possible to set a breakpoint before sending the address CRC byte and trace the bootloader operation to the logic which generates the ACK or NAK, but as it's in ROM all you would probably learn is precisely what is or (apparently erroneously) is not allowed.
Best Answer
The bootloader and the basic peripheral library is in ROM on the ESP8266 chip itself. What you write to using esptool is the external flash chip. Due to the way the content of this flash chip is loaded into RAM (either 'permanently' or only cached) this ROM image is split into segments. (There can be more segments than these two, for instance for data.)
Side note: this blogpost by me has an overview of the various ESP8266 modules.