It appears that the 'problem' might actually be related to the AutoReconnect feature rather than AutoConnect. From what I can loosely understand, if AutoReconnect is disabled then I think the WiFi.waitForConnectResult() function doesn't work as you might expect and seems to have a timeout of 60s. So the reason for the 75s overall timeout is 15s due to (rESP8266WiFi.cpp - line 33 - 41) plus 60s whilst the function waits for the result of WiFi.waitForConnectResult().
I couldn't find a way (that worked) to adjust the 60s timeout for WiFi.waitForConnectResult(), so instead I tried replacing
return WiFi.waitForConnectResult() == WL_CONNECTED;
with
return WiFi.status() == WL_CONNECTED;
in rESP8266WiFi.cpp. This worked in the sense that the timeout was now always 15s and you did still get a connected or not connected indication at the end of it.
However... the same was not true for the AsyncConnect method. In this case the function is looking for WiFi.status() codes other than idle status and disconnect before it returns with a connection status (and presumably pulls the function out of the polling mechanism at that point). From my experimentation I don't think the WiFi.status codes return what you might expect from their descriptions in this situation.
Whilst I'm not so concerned about not getting a 'failed to connect' callback indication from AsynConnect, what I am concerned about is the possibility that by regularly calling AsyncConnect (e.g let's say every 30s) before the polling callback returns with anything, that the mechanism might then be stacking up more 'stuff' in the polling queue than it will remove - eventually leading to overflows or stack issues perhaps?. I don't know if it works like that so sorry for the poor description but hope you understand what I mean. If so, would it be possible for a call to the AsyncConnect function to 'unstack' a previous one, or is that implicit anyway ?
In terms of getting a negative connect indication within a shorter timeout can there be a way to implement a controlled timeout for the Async polling like there is for the non async method? E.g by using some global variable to track the time?. My C is too poor for me to work out how to implement this, nor do I know that doing this won't mess up something else in the bigger picture.. On the other hand if calling AsyncConnect before it has chance to do it's callback is ok then I can just implement a timeout in the B4R domain.
Why do I need to disable AutoReconnect in the first place you might ask? Because it seems to mess with the reliability of connections through the Access Point which I'm turning back on when the main WiFi connection drops for any prolonged period (so that you can still communicate with the device in some way). I haven't figured that one out yet... possibly AutoReconnect is changing WiFi modes whilst it's hunting, certainly it will switch radio channels away from the AP default for one thing, since only one radio, but that's not the only cause.
NB. Whilst trying to find a way to change the inherent WaitForConnectResult timeout I came across the below but not quite sure where to use it. My experimantation of placing it in various places with a different timeout values haven't worked so far
the function's prototype is
int8_t waitForConnectResult(unsigned long timeoutLength = 60000);