We aren't finished with that Set Gid bit yet... Unix has a concept of file locking. File locking is beyond the scope of this thread. But you need to know that file locking comes in two flavors: advisory and manditory. Which flavor applies to a particular file depending on the permission settings. If the group execute bit is off but the setgid bit is on, any file locks on that file are manditory.

Useless Bit Combination?

Every reference that I have seen says that setgid on / group execute off is a otherwise useless combination. Even Richard Stevens (in Advanced Programming in the Unix Environment) says "Since the set-group-ID bit makes no sense when the group-execute bit is off, the designers of SVR3 chose this way to specify that the locking for a file is to be maditory locking and not advisory locking."

Well consider this case: Fred runs the Human Resources department. Fred and his group often need to lookup the vacation days used for employees. Fred decides to write a program so employees can lookup their own vacation days used. For security, Fred makes this program do a lot of logging. Fred decides that he doesn't want his group to use this program. They have other tools that won't clutter his log. So Fred does:
chown fred:hr vdays
chmod 2701 vdays
Now the vdays program cannot be run by members of hr (except fred). But it can be run by everyone else. And it will assume the gid of hr when it does run. I have written a test program, set it up like this, and have run it on both Solaris and HP-UX. It works.

Effect on ls output

While this bit combination may be useful is some limited cases, for better or worse, it will have two effects. The vdays program does work, but if a lock is attempted on the file, it will be manditory. As a practical matter, this would impact only an occasional program like a debugger. But ls may treat this bit combination differently. I have seen both of these...