The answer from ST is obviously correct. However, depending on your precise requirements, it might be possible. If you indend to use the second flash for a proper flash file system, then you'd in general never access the flash directly from your application, but only via the file system layer, which in turn would employ appropriate low level read and write fuctions. If these low level functions would be located in the internal flash, and all interrupt service routines as well, it would be possible. Just flip the FSEL bit in QSPI interface upon entering the read/write functions, and revert to the old setting upon return. Data goes via RAM anyway, so no problem.
Of course, there are more implications, i. e. if you want non-blocking i/o or an operating systems, you'd have to toggle the FSEL bit back on context switch and forth when resuming the i/o. So, it *IS* certainly possible, but complicated. Like in the old days of 16-bit address busses with bank switching to support memory beyond 64k.
Whether you actually need non-blocking i/o is worth a second thought: For reads, the QSPI will deliver the data almost instantly, so no problem. For writes and in particular erase it's different. However, after pushing the data to be written into the page buffer of the flash (again, no wait required) or issuing an erase command, it's possible to switch *immediately* to the other flash chip: As soon as CS goes inactive, the flash starts the page write or erase operation and does *NOT* need any further activity by the SPI master.
It sufficiently to check periodically the flash's status register.
