We may want to take this to the forum and/or add telemetry data on used Operating System to the update mechanism of OpenMPT.

Since r6705, there is telemetry for Windows/Wine versions in the update checker.

I don't know about this. I came to ModPlug thru Windows 98 (actually an emulator of it on Mac), and I'd still be using it if I didn't have other applications that motivated me to get a Windows computer. I'm still on XP, but computers are often handed down that use obsolete platforms, and I'd hate to lose a potential user/member/colleague because our software is one version beyond their reach.
I have no intention of moving "up" from Windows XP, so when am I gonna get muscled out? (rhetorical question to make a point)

Now if you're doing an overhaul of the GUI and you need to do a serious update to the features, for which we simply didn't have the tech way back when ModPlug was open-sourced, that's different. Otherwise if you're only doing it for convenience's sake, maybe you can brainstorm a workaround, so that older computers are not once again denied a great old-school application.

Yes, perhaps a thread in the forums will bring us to a nice compromise or win-win answer....

I don't know about this. I came to ModPlug thru Windows 98 (actually an emulator of it on Mac), and I'd still be using it if I didn't have other applications that motivated me to get a Windows computer.

This is 2016, not 2006. Most major software that people use no longer runs on Windows 98 or Windows 2000, making OpenMPT a very rare exception. You can always use an old version of OpenMPT on Windows 98 if you really must. Besides, what about the theortical Windows 95 users out there which also cannot use OpenMPT anymore since... more than 10 years ago?

Otherwise if you're only doing it for convenience's sake, maybe you can brainstorm a workaround, so that older computers are not once again denied a great old-school application.

The "convenience" we are talking about here directly correlates with motivation to work on the code at all. If the code is complicated to write (which it is when having to target C++98), it's also not fun to write. The "workaround" you are talking about is not upgrading to C++11, making writing new, maintainable code more complicated than necessary.

(besides, it is very well possible that Win98SE and WinME may still be supported through KernelEx - only dropping Win2k support in the end. That entirely depends on which APIs are available in KernelEx and which are not. manx' list is just a worst-case assumption in this regard.)

As far as I know, there is no way whatsoever to make a Win 9x kernel load MSVC 2010 (or later) binaries at all. I think I did try that in the past. After all, as far as I know, this was the one and only reason to still support MSVC 2008 at all.
Thus, Win98SE and WinME support will die.

I have no intention of moving "up" from Windows XP, so when am I gonna get muscled out?

I think it is generally (as a goal to strive for) wise to support at least two versions (i.e. the latest two) of Visual Studio. Thus, as long as the second to latest Visual Studio release still supports Windows XP, it probably will not go away (for Win32old build variants). Full functionality already currently requires Windows 7 / 8.1 (mostly because of compressed lossy sample import).
Visual Studio 2015 still supports XP, thus Windows XP support is here to stay at least for the next 2 years, I guess. I cannot predict the future of course, and there may be or come around other reasons to remove Windows XP at some point.
Currently, however, I do not think there is much to gain from removing Windows XP support. Not so much because of Windows XP itself, but because of Wine, which in most aspects implements functionality roughly equivalent to Windows XP API level.

I again just lost about 2 hours fighting broken compilers.

Removing support for MSVC 2008, MSVC 2010, MSVC 2012 will remove support for the following CPUs in OpenMPT and libopenmpt builds:

• Cyrix 6x86L
• Rise mP6
• IDT Winchip C6
• IDT Winchip 2

vs2015xp builds crash on Wine 1.0.1

vs2015xp builds work on Wine 1.4.1

I think it would be worth the effort to still support GCC 4.6 in some kind of ANCIENT configuration (like we are currently doing for MSVC 2008, GCC 4.1, GCC 4.2, GCC 4.3) because Debian 7 still uses GCC 4.6 on non-x86 systems.
Our only real hardware big-endian system is on Debian 6 and cannot be upgraded. Installing Debian 7 compilers there might be feasible though.

Forum post is at https://forum.openmpt.org/index.php?topic=5708.0 .

Support for VS2008, GCC 4.1, GCC 4.2, GCC 4.3 is gone now (r7005, r7006, r7007, r7009).

GCC 4.7 has severe problems with moderate use of constexpr, thus, to get really usable C++11 support, GCC 4.7 support would also have to be removed.

So far, we have only dropped 4 compilers:

• MSVC 2008
• GCC 4.1
• GCC 4.2
• GCC 4.3

Various C++ features would require support for various different compilers to be removed:

random:
gcc 4.4

nullptr:
gcc 4.4
gcc 4.5

chrono:
vs 2010

enum class:
vs 2010

inttypes:
vs 2010
vs 2012

variadic templates:
vs 2010
vs 2012

default/delete:
vs 2010
vs 2012

template aliases:
gcc 4.4
gcc 4.5
gcc 4.6
vs 2010
vs 2012

noexcept:
gcc 4.4
gcc 4.5
vs 2010
vs 2012
vs 2013

constexpr (c++11):
gcc 4.4
gcc 4.5
gcc 4.6
gcc 4.7
clang 3.0
vs 2010
vs 2012
vs 2013

atomic:
clang 3.0
vs 2010

mutex:
clang 3.0
clang 3.1
vs 2010

thread:
clang 3.0
clang 3.1
clang 3.2
clang 3.3
clang 3.4
clang 3.5
vs 2010

...

type_traits working for array types:
vs 2010
vs 2012
vs 2013

type_traits is_trivially_copyable:
gcc 4.4
gcc 4.5
gcc 4.6
gcc 4.7
gcc 4.8
gcc 4.9
gcc 5.0
clang 3.0
clang 3.1
clang 3.2
clang 3.3
clang 3.4
vs 2010

r8006 to r8014 remove support for GCC 4.4, 4.5, 4.6, 4.7, clang 3.0, 3.1, 3.2, 3.3, vs 2010, 2012, 2013.

This means, we can now start using at least the following C++ features unconditionally (this list is incomplete):

• random
• nullptr
• chrono
• enum class
• inttypes
• variadic templates
• default/delete
• template aliases
• noexcept
• constexpr (c++11)
• atomic
• type_traits working for array types

The following features still require attention (the std:: version is not available for Win32old and Win64old build because of Wine compatibility):

• mutex (not available in threadless environments like emscripten)

The following features are still not available unconditionally:

• thread (not available in threadless environments like emscripten)
  • clang 3.4
  • clang 3.5
• type_traits is_trivially_copyable
  • gcc 4.8
  • gcc 4.9
  • gcc 5.0
  • clang 3.4