I'm too lazy to make a table and going into details would take pages of text on each and every of those points - so you get this:
What OS? Because there is DOS and "DOS" aka Windows 95+ command line. You might be able to get away with some tricks on 95/98 but not on NT kernels.
In general, the well-established methods work and are reliable. So real mode XMS/EMS will work on anything 286+ and all compilers, though for Basic and other high-level languages you might need to write custom assembly procedures to link with the program. Basic interpreters - not sure but probably in "forget it" category.
XMS is somewhat slow though as it requires copying the data to a window/buffer below 1MB, and to even do that you need to enter and exit protected mode. Which can be slow on 286 and even on 386 not all BIOSes deal with this efficiently (though HIMEM migh be able to work-around that with LOADALL instruction). True EMS is fast, and so is emulated EMS because it uses 386 paging, but the early standard still requires a transfer window in most cases and the later versions might not be available except on late 386+ / DOS 5+ machines. Also, emulated EMS will put the CPU in V86 mode and also most managers will take a few hundred kBs of RAM (even if mostly above 1MB).
Unreal mode is fun and great on paper. In reality it's difficult to pull off and will have issues on some machines. Forget about any memory managers, XMS including, unless it's physical (and EMS is mostly a 286 thing). In theory you could also do Unreal on a 286 but that'll only give you access to upper 64kB. So, Unreal equals 386 or later CPU.
For Unreal you will need a lot of custom assembly, need to control A20 line mask, and while it's possible to use high-level compilers the code mix will be neither trivial not efficient. Plus to actually use any high memory or 386+ registers you have to add 0x66/0x67 prefixes to all instructions, that bloats and slows down the code.
286 protected mode - a bit faster than XMS in real mode but good luck finding compilers and DOS-extenders and the docs, and then building a reasonably fast dev box that is not a 286 itself. Unless you need to support 286 class CPUs I'd say forget it, or go wild and don't care about compatibility too much. Or prepare to suffer.
386 protected mode - that's probably what you want. Especially since you can just use OpenWatcom with DOS4G/W - or some replacement like PMODE/W. Or you can just code everything in PMODE DOS-extended assembly, I used to do that. C is easier though. It's well travelled path and compatible with memory managers, VCPI/DPMI as well so no big issues (if any at all) with Windows including NT kernels.
There is also DJGPP and HighC and other compilers but I'm only familiar with Watcom and let me put it this way: There is a reason DOS extenders became so popular (instead of every program having it's own way of doing things), and among them DOS4G became a de-facto standard on the PC thanks to games. Watcom C compiler was also fastest 386/486 compiler, even for real mode. Today I guess a modern gcc version that can target i386 might beat it but you won't get any DOS support for gcc.
If this is for-fun personal project then go ahead and start with Unreal. You'll learn a lot and then abandon this idea with a switch to DOS extender. Assembly or C, it's more time spent on doing interesting things than figuring out very obscure PC architectural details that prevent your program from working.