I'm afraid I don't understand your comment about the link not being relevant. It precisely states ksh is taking specific measures against exploits when called as a suid script and it explains how modern OSes, like Solaris, prevent other exploits to success.
That was my question. Do you have a link or something pointing to a place where these rules are documented ?
I stand corrected here. You certainly were expecting id to display the user's groups but the default Solaris id command doesn't do it. If I replace id with /usr/gnu/bin/id, guest is indeed member of both his original group and jlliagre's one.
I believe (but am not 100% sure yet) my example doesn't elevate the script permissions, it switches them from those of an unprivileged user to another unprivileged user. However, I probably should do more checking to be sure fine grained privileges granted to jlliagre's account do not interfere with my sample results.

---------- Post updated at 01:25 ---------- Previous update was at 00:40 ----------

My example was on "Oracle Solaris 11 Express snv_146 X86".
It works the same way on OpenIndiana build 151a, Solaris 10 and probably all previous SVR4.0 based Solaris releases.
I just tried on Solaris 11 FCS and the behavior is slightly different and actually better.
The suid bit still allows for an unreadable script to be executable but the euid is not changed anymore.
I don't think ksh version matters but I'm using what /bin/ksh refers to, i.e. ksh88 on Solaris 10 and likely ksh93t+ on all the SunOS 5.11 based OSes.
Indeed. I commented about what I know/read about OSes supporting or not suid scripts in post #12 https://www.unix.com/302592028-post12.html