(Here's my research, done some months ago, may be out of date or incorrect altogether. It's also simplified to be understandable for non-FOSS-geeks.)
John,
getting it to work on the default rpi install will be hard. Omxplayer is using some BCM-specific code to push frames into the GPU and can thus get it working that way - this is completely incompatible with anything else in the linux ecosystem and won't work for X11, Wayland or anything else. You could write a full UI that utilizes that, but it would be similar (from what I understood) to MDAC(1) in its limitations and "low level work" needed.
You could have a VGA console on one and a framebuffer on the other, but I'm assuming you want two "graphical" outputs, not one 80x24 teletype terminal and one graphical output.
The dual-monitor video you linked is a workaround for that - a displaylink USB-to-DVI plug that basically saturates your USB throughput so you can get a second, very low-framerate, display.
Now, the upstream Linux kernel has been slowly, since ~2011, re-implementing "the proper way" what the RPi foundation/community have done in closed-source binary blobs and incompatible patches, so now there are essentially two independent implementations of the same thing. Fairly recently (2016-2017), the graphics stack has become usable thanks mainly to Eric Anholt (he runs / used to run a blog about the changes,
http://anholt.livejournal.com/) and very recently, Sept. 2017, even added support for the official DSI-based 7" touchscreen was added (I remember him having big issues with making DSI work). On the other hand, support for DPI is there for some time and dual-display should be working, see
https://anholt.livejournal.com/45862.html . He even added the display he worked with to the panel-simple.c file,
https://git.kernel.org/pub/scm/linu.../?id=e8b6f561b2eeb667aff932d9a5af5a6279221283 , however, as far as I was able to gather, the implementation is not limited to it, any DPI panel supported by the kernel and defined in your devicetree should be usable,
https://git.kernel.org/pub/scm/linu...umentation/devicetree/bindings/display/panel/ .
Since all this needs a "clean" Linux kernel and a GNU/Linux distribution to go with it, as opposed to the RPi foundation customizations, it may be tricky to get it working from the ground up - this is what I was working on earlier. Fortunately, some people at Debian provide a fairly up-to-date build, a ready-to-use image with the kernel and everything compiled and ready to use on RPi3 -
https://wiki.debian.org/RaspberryPi3 .
The downside or upside is that, because they're not bringing the "legacy" RPi baggage, they can choose to run aarch64 architecture (the 64-bit ARM), supported by RPi3. This makes some operations potentially faster, allows you to build your software potentially faster (extra GP registers and more), but also renders most binary closed-source software unusable out-of-the-box (like one of the 3rd party plugins I was preparing, not HQPlayer, the other one) because the vast majority of the RPi community assumes you're running the 32-bit RPi foundation based system.
Now, you can probably run 32bit ARM on aarch64 given supporting libraries, you can also rebuild the upstream Linux kernel and userspace for 32bit (which is what I was doing), sort-of fixing the problem, but it's an extra effort compared to just using a ready-made image. The image should, however, allow you (or one of your minions, hehe) to assess if such path is worth pursuing. I can confirm that on my RPi3, I can see one framebuffer device, so the graphics support is there, but I don't have a DPI display defined in devicetree to see if this implementation supports both using a standard interface, usable by X11 and others.
Hopefully this helps somewhat.
