Your probability of this, in any kind of simplistic fashion, is about there with winged pig aerobatics teams doing spontaneous air displays
First off, the two systems use totally different architectures - so any 'porting' of software/firmwire is going to require (for native implementation), a port/rewrite of firmware and XMB (i'm assuming the XMB Gui is still used on the PS4) to x86-64 from PPC/CELL form, or at the very least, an 'machine' emulator to emulate the Cell processor inside of an x86-64 architecture or compatibility layer approach (i.e. similar to how Wine works in Linux where it combines some native versions of support files and some very clever integration to fall somewhere between near native and emulation). As for VM/Hypervisor integration :-
Note that the the NG consoles, in various ways, effectively run the aspects of software support in secure VHD type virtual storage - so to see or peek at anything, you've got to be able to access the 'virtual hdd' that all the real stuff exists within, and the partitions within it and these are encrypted typically.
So whilst the 'game' or 'app' side could exist in a 'game os' VM, over a Unix or Windows OS base (which the PS4 and XBOX One use a Unix and Windows 10 derivative respectively as their 'OS' base, and the bios differs somewhat, to my understanding, similar to how MAC's and Chromebooks use non-standard BIOS's), you are talking a multi-level task at best, to cracking/jailbreaking these NG consoles as opposed to attempting to crack an embedded OS based device which is essential PS2/PS3/WII etc fare (fairly conventional stuff for consoles, to work as embedded OS devices).
Bear in mind, also, that whilst the skills required to crack and dissect embedded OS device operation (which is where they stood cracking the PS3) are a bit specialist at the very least, embedded system development (mostly in the microcontroller based field) is a thriving and healty pastime (you could say, it's almost the real 'hacking' in the old-school original context). This, combined with interest and knowledge and undoubtably some expertise with embedded OS fundamentals, still required a fairly steep learning curve before the older consoles got their JB's to be stable, let alone repeatable and not guaranteeed to brick if you so much as sneezed too hard.
So whilst working in the context of virtual storage and hypervisors/VM's should technically mean there's more scope for a larger audience of 'hackers' to have a go with the NG consoles (i.e.not having to learn what is effectively an alien 'old school' way of working, programming and dev in the mc/embedded os world), when you are talking 'microcosms' (worlds within worlds) which is kinda what OS's running in sandboxes within an OS, or OS inside of an OS inside of a just-enough Hypervisor 'OS' is comparable to - and keeping in mind that native communication between these layers and 'worlds' (thanks to sandboxing) is restricted somewhat, we are talking a pretty steep curve here and thats without encryption matters that are almost certainly going to come into it.
Just remember a simple rule of thumb - more often that not, a seemingly obvious 'simplistic' approach that almost seems to hand itself to you on a plate (which porting PS firmware could be seen as), ends up being neither very effective (in terms of effort required for what piecemeal success you get) or particularly elegant or robust. A 'patched together' method of analysing something that's closed off is ok for trying to reverse engineer on one level, but it's merely one percent of the process at best.
Anyone old enough to remember the 'voyager' smart card soft emulators and the later PIC-chip based fake 'smart cards' that replicated the functions of decoding and providing smart card function respectively - will probably recall that is wasn't data-sniffing that made the card replicator happen, someone literally ended up slicing smart cards open to map their circuitry and microcontroller functions and sniff at integrated low level to learn anything even close to replicating the functions. This wasn't helped at all by the fact Videocrypt was quite a secure encryption and if it had relied on 'data sniffing' and poking at bytes to see the reactions to crack it, we'd be here (meaning those who worked on it back in the day) today still working on it using schoolbook 'hacking 101' simplistic 'in principle' methods.
If it feels simple, if it kinda almost lays itself out in your mind from the outset with absolute clarity, you can almost bet easy safe money it's never going to work out anything like how the process feels like it'll work.