What you see in the video is exactly how the app works and displays on all platforms, except the window around the black area, which is Windows-specific.
If you follow the exact steps with the files in their correct places (you see the filenames of some of the ROMs in the video as well), the app should still act the way you see in the video. There are a few little changes in slightly newer builds until the current builds, but those mainly account for slight improvements in the menus and some ease of accessability options being added (those changes are mentioned in the comments of said video).
The basic way of setting it up didn't change though, with regards to restarting the application or performing a hard reboot of the emulated system and saving the setting changes and performing machine-specific tasks(like flashing a XT-IDE ROM for hard-disk support(required for XT/AT/Compaq only) or configuring the BIOS that's being run).
Although stuff like mouse clicks and keyboard inputs aren't shown. All of the emulator's own rendered text can be clicked or tapped(using touch inputs), except when performing choosing of a list (like mounted disk selection from a file list).
But even so, those inputs can just easily be done using the cursor keys(left,up,down,right) and enter/carriage return, backspace(for opening the menu) and escape(to cancel/return to a parent menu (or save&resume when in the main menu and resuming without restarting emulation to apply the settings is supported. Otherwise, navigate to the main menu and choose the appropriate save(or discard)&restart emulator option)).
At what point is the video inaccurate then (other than new options being added in later versions or the mentioned changes in the comments)? When I made the video(with said release of the app at the time), it ran exactly as you see in the video.
Also, if the window doesn't display anything at all, it's SDL that's at fault, not the app itself(which just passes the graphical data to SDL to display). There are fixed issues with the SDL library in later versions, so you could update the DLL to a later version for that.
As for UniPCemu bugfixes themselves, not much has changed since the last release (other than a texture reload fix in the latest commits, which can be triggered by minimizing and then restoring the app). Those are all bugs I know of (I use Windows to mainly test the application and develop on it as well, so if I find a bug, I usually fix it right away if possible). Current commits only still have the texture bug(minimize and restore the window to fix that), but that's more an issue of SDL failing to handle it correctly itself without starting to spam texture reloading messages to the app while the app is experiencing such an issue(it will tell the app it should update it's textures even though it's updating it's textures asap when disconnecting RDP, but keeps spamming the message to grind the app to a halt until RDP either reconnects or the user logs in locally on the machine with the app having window focus).
Edit: There has been a slight update forcing the app to perform scaling to the size of the desktop, but that only happens on high DPI monitors(more than 96 DPI). That simply changes it to mobile mode besides the scaling, for better readability. It can also be applied manually using a command line parameter documented in the manual.
Disabling said automatic behaviour is currently not possible, because otherwise the app would become unusable (postage stamp size as the user who reported the issue said would happen). Try to reduce the DPI setting is the only option in that case (to be no more than 96 DPI).