I'm not 100% sure this is a high risk, but from the looks of it, it could be a possibile security issue not just with your autologin hacks, but with the actual cores of all xoops versions.
I have already made these changes in impresscms 1.1.2 but thought i'd run this by you for better clarification.
the issue at hand is in the setcookie() function when you are using SSL/HTTPS.
if we take a look at your hack (relevant part)
$expire = time() + ( defined('XOOPS_AUTOLOGIN_LIFETIME') ? XOOPS_AUTOLOGIN_LIFETIME : 604800 ) ; // 1 week default
setcookie('autologin_uname', $uname, $expire, $xoops_cookie_path, '', 0);
$Ynj = date( 'Y-n-j' ) ;
setcookie('autologin_pass', $Ynj . ':' . md5( $user->getVar('pass') . XOOPS_DB_PASS . XOOPS_DB_PREFIX . $Ynj ) , $expire, $xoops_cookie_path, '', 0);
that's all well & good when using normal HTTP protocols.
but if you wish to use SSL/HTTPS, then there's the issue.
the issue is that in the setcookie() function, the parameter for $secure is set to '0'
in SSL this should be set to true or 1. because if $secure is not enabled when using SSL, it is possible to trick the browser into sending the secure cookie data over an insecure HTTP. setting this to 1 prevents the cookie from being sent over non-https.
this isn't just your hack though, this issue exists in all xoops cores that i know of. though i haven't checked Xcube, i did browse through legacy and noticed the secure parameter isn't set when using ssl there either.