The DEFAULT Type mapper correct here? From the header file:

//
// Only the UNICODE version of the LM APIs are available on NT.
// Non-UNICODE version on other platforms
//
#if defined( _WIN32_WINNT ) || defined( WINNT ) || defined( __midl )
|| defined( FORCE_UNICODE )
#define LMSTR LPWSTR
#define LMCSTR LPCWSTR
#else
#define LMSTR LPSTR
#define LMCSTR LPCSTR
#endif

I risk a guess, on recent Windows Versions (i.e. everything post W2K) - is WIN32_WINNT or WINNT defined? If so, this would need the UNICODE mapper, if not some more logic is necessary.

Good catch. Those strings are always Unicode.

So if they are mapped directly to WString, we don't need any type mapper.

The string mapping might prove to be problematic, the headers are not consistent. See the differerence:

NetGetJoinInformation(
__in_opt IN LPCWSTR lpServer OPTIONAL,
__out_opt OUT LPWSTR *lpNameBuffer,
OUT PNETSETUP_JOIN_STATUS BufferType
);

In this case the function call always expects a unicode string. The same is not true for:

NetSessionEnum (
__in_opt IN LMSTR servername OPTIONAL,
__in_opt IN LMSTR UncClientName OPTIONAL,
__in_opt IN LMSTR username OPTIONAL,
IN DWORD level,
__out OUT LPBYTE *bufptr,
IN DWORD prefmaxlen,
__out OUT LPDWORD entriesread,
__out_opt OUT LPDWORD totalentries,
__inout_opt IN OUT LPDWORD resume_handle OPTIONAL
);

With the definition of LMSTR see comment in SESSION_INFO_10 for the definition. And it depends on the interpretation there.

Per above, LMSTR is always Unicode. So these should be WString.

I would add a javadoc comment to the three parameters, that they exist only to enable structure size calculation. I would also make the three fields final (see https://java-native-access.github.io/jna/5.5.0/javadoc/overview-summary.html -> "read-only" fields).

Reading from native memory and will still work. Even a setter should work that way.

Regarding final that requires the fields be initialized in the constructor. When constructing from a Pointer this works. Should I then remove the no-arg constructor?

Actually... as arrays, final doesn't really change writing to the contents. So this doesn't prevent changing the contents but does fix the length, and thus the structure offsets. Not really "read-only" but still a good idea, probably JNA-wide for arrays in structures...

Would it make sense to move this to Wtsapi32.java as

public interface _WTS_INFO_CLASS {
    int WTSClientAddress = 14;
    int WTSClientProtocolType = 16;
    int WTSSessionInfo = 24;
}

?

Sure... although I'd probably map the entire enum there. I was being a bit lazy...