According to the specification, _NET_WM_WINDOW_OPACITY values range from opaque (0xffffffff) to transparent (0x0). This is also how Mutter used to parse these values before 3.12 (ref: 1db95bc32be97028aae5f0f9d616cfe3cbfafbf6)

In src/compositor/meta-window-actor.c:

 meta_window_actor_update_opacity() {
 ...
       opacity = (guint8)((gfloat)value * 255.0 / ((gfloat)0xffffffff));
 ...
   clutter_actor_set_opacity (self->priv->actor, opacity);
 }

Now, however, the value is directly used and assumed to lie between 0x0 and 0xff:

In src/compositor/meta-window-actor.c:

 meta_window_actor_update_opacity() {
 ...
   clutter_actor_set_opacity (self->priv->actor, window->opacity);
 }

In src/core/window-props.c:

reload_window_opacity() {
...
  meta_window_set_opacity (window, requested_value);
...
}

Due to the way clutter handles the out-of-range opacity value, this causes the opacity value to be truncated to the last two digits. For instance, 0x7fffffff (50%) becomes 0xff (100%).

The attached patch fixes this by changing it *only* when the Atom value is read, in reload_window_opacity(). 

AIUI, mutter now always takes opacity values between 0 and 255? If so, it probably also makes sense to change the prototype of meta_window_set_opacity () to be "guint8 opacity" so that there's compiler warnings if this happens again, but that's your call.