At least since <https://cgit.freedesktop.org/libreoffice/core/commit/?id=4479090e6063f6106c9cf08473f3cac1b12407e2> "Bring back the Duden hack" (June 2013), what uwinapi.dll exports is
EXPORTS
GetShortPathNameW PRIVATE
snprintf
snwprintf
vsnprintf
vsnwprintf
(cf. sal/systools/win32/uwinapi/uwinapi.def, and whatever the "PRIVATE" means).
According to <https://msdn.microsoft.com/en-us/library/windows/desktop/aa364989(v=vs.85).aspx> "GetShortPathName function", GetShortPathNameW/GetShortPathNameA are available in Kernel32.dll since Windows XP, so that one probably isn't relevant any longer anyway.
vsnprintf is available in the MSVC runtime at least since MSVC 2013, probably even earlier.
snprintf is availabe in the MSVC runtime since MSVC 2015.snwprintf and vsnwprintf appear to be inventions of our own. Depending on whether _UNICODE is defined, sntprintf and vsntprintf are defined to those in include/systools/win32/snprintf.h, but sntprintf and vsntprintf in turn appear to be inventions of our own, too. (There are, however, _snwprintf, _vsnwprintf, __sntprintf, and _vsntprintf available in the MSVC runtime at least since MSVC 2013, probably even earlier.) This smells a bit like we're cargo-culting those around while they should actually have been removed long ago.
Since <https://cgit.freedesktop.org/libreoffice/core/commit/?id=0c9ddb24ee0388d03c313caf5a45f1aa26049781> "Don't redefine snprintf as VS 2015 supports ISO standard" (September 2015), inclusion of the four functions snprintf, snwprintf, vsnprintf, and vsnwprintf in uwinapi.dll is made conditional on building with < MSVC 2015. That means that for LO 5.4 (where we bumped the baseline to MSVC 2015), the uwingapi.dll in official TDF builds will only export the one function GetShortPathNameW.
And whether the uwinapi functionality is exported through the SDK is somewhat ill-specified: For one, from the two commits mentioned above, it looks like at least the Duden extension depended on it in some form. For another, we provide include/systools/win32/snprintf.h in the SDK. (Traceable back to <https://cgit.freedesktop.org/libreoffice/core/commit/?id=6c7659b584ea7ed3652ca4eb9a2297f36310c365> "move URE headers to include/", April 2013; not sure if we even included more files from include/systools/win32/ prior to that.)
Now, <https://gerrit.libreoffice.org/#/c/23198/> "gbuild: Remove MSVC 2013 legacy code", among other things, tries to remove uwinapi.dll and its include/systools/win32/ include files completely. My first reaction was to decouple the actual uwinapi removal from the other clean-up done there. However, I only later noticed that the remaining uwinapi is almost empty anyway (due to <https://cgit.freedesktop.org/libreoffice/core/commit/?id=0c9ddb24ee0388d03c313caf5a45f1aa26049781> "Don't redefine snprintf as VS 2015 supports ISO standard" as described above).
So, instead of disentangling that monster Gerrit change, deciding which parts are still relevant for the hypothetical left-alive uwinapi and would thus need to be retained, I guess we can just as well bite the bullet /now/ and decided how to proceed with uwinapi.
In the light of all the above, my suggestion now would be to discontinue uwinapi in LO 5.4. Remove include/systools/win32/snprintf.h from the SDK and add to the release notes that that include file and uwinapi.dll itself (however 3rd party code would have been able to rely on it in the past) are gone. This might mean that old extensions like the Duden one no longer work with 5.4, but presumably we already accidentally broke compatibility with those a while ago, anyway. (And if/when we discontinue 32 bit builds of LO on Windows, support for such legacy extensions becomes moot anyway.)
Thoughts?