FULL PRODUCT VERSION :
 "1.8.0_102" 
"1.8.0_91"
At the least.  No evidence of changes in later versions.

FULL OS VERSION :
Multiple Linux distributions, also Mac OS X, potentially windows and Solaris too

EXTRA RELEVANT SYSTEM CONFIGURATION :
Confirmed across multiple Java versions and system configurations

A DESCRIPTION OF THE PROBLEM :
Invoking a program using the G1 garbage collector with the flag -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses  silently does nothing with, rather than behaving as -XX:+ExplicitGCInvokesConcurrent or throwing an error. 

For people migrating from CMS garbage collector to G1, this is a serious problem, because they are likely to retain the non CMS-specific settings.  In CMS land, ExplicitGCInvokesConcurrentAndUnloadsClasses is a safe option used to help ensure that class cleanup is performed when needed (example, with RMI) without the gigantic stop the world pauses from Full GC. 

If you use this option by mistake with G1, as I have now seen on several larger systems in including in production settings... then you silently get long stop-the-world pauses (10s of seconds, even!).

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.  Run an application that includes or allows you to execute explicit System.gc() calls, using these settings:

-Xloggc:gc-%t.log -XX:+PrintGCDetails -XX:+PrintGCCause -XX:+UseG1GC -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

2. Trigger System.gc() in the application
3. Look at GC logs for FullGC
4.  Run the same but use -XX:+ExplicitGCInvokesConcurrent instead of  -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
5. Look at GC logs - concurrent GC is invoked. 



EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: 

ExplicitGCInvokesConcurrentAndUnloadsClasses reverts to just ExplicitGCInvokesConcurrent behavior (possibly printing a warning statement).  Calls to System.gc() invoke the G1 concurrently, not the serial full GC. 

GC logs should show something like his: 

331.327: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: requested by GC cause, GC cause: System.gc()]
6635 {Heap before GC invocations=72 (full 0):

ACTUAL: 

Full GC is invoked.  No warning is printed, no error generated.  

GC Logs show lines like this: 

2016-11-09T20:25:03.835+0000: 117.855: [Full GC (System.gc())
ERROR MESSAGES/STACK TRACES THAT OCCUR :
See expected and actual for the GC log messages

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class Main {
    public static void main(String[] args) {
        try {
            Thread.sleep(100);    
        } catch (InterruptedException ie) {
            
        }
        System.gc();
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
No workaround possible.  The argument doesn't work -- you have to know this, and not use it.