Hmm. I don't know what the defaults are for 'thread per connection' mode. I use that mode and everything is fine, so unless it's a new bug... I kind of suspect there might be no defaults and you have to specify the parameters. That is, you may need to tell MHD how many threads to create/maintain/allow. Otherwise, I don't see anything wrong with your 'start_daemon' call. That 'connectionCallback' function of yours really should be called.
I know the 'use select internally' mode is working for you, but if you'd like to try to continue using 'thread per connection', you could try adding something like the following to your 'start_daemon' call:
MHD_OPTION_CONNECTION_LIMIT, // specifies that the next arg is the max number of simultaneous connections
(unsigned int)10, // the number of permitted simultaneous connections
MHD_OPTION_CONNECTION_TIMEOUT, // specifies that the next arg is how long any given connection can live
(unsigned int)60, // the number of seconds connections are allowed to live (0 would allow them to live indefinitely)
If you don't have any long-lived requests, 'use select internally' is likely a good choice anyway. You just have to be mindful that you can't service multiple requests simultaneously (unless you use the suspend/resume functionality and/or a thread pool).
Regarding the static method in the C++ class - I suspect you're right. That should work. Personally, I'm having it call a C function that has been 'externed' (to avoid any chance of function name mangling) and then have that call back into my C++ class. One way or the other, I need access to persistent data in my class, so a static method versus a C function aren't really all that different.