Hello,
as suggested by Yves-Alexis I report here further informations about the missing PAM_CHANGE_EXPIRED_AUTHTOK flag.
I have spent my day on reading the PAM code after we found a problem during the test phase of our LDAP authentication environment. Initially we've fixed our lightdm package and filled a Debian/Ubuntu bug (#735670/#869501, please note that #869501 is actually a private issue, so maybe you can't read it).

Today I have spent the morning looking about the implications of this missing flag in the lightdm code.

The PAM_CHANGE_EXPIRED_AUTHTOK flag involvs many pam modules.
I'm going to trace down and prepare a report about this.

What is more interesting is that the standard Debian pam package is involved!

~/dev/pam/pam-1.1.3$ grep -r PAM_CHANGE_EXPIRED_AUTHTOK * | grep modules
modules/pam_stress/pam_stress.c:	       && (flags & PAM_CHANGE_EXPIRED_AUTHTOK)
modules/pam_unix/support.c:	if (getuid() == 0 && !(flags & PAM_CHANGE_EXPIRED_AUTHTOK)) {
modules/pam_cracklib/pam_cracklib.c:	    if (getuid() || (flags & PAM_CHANGE_EXPIRED_AUTHTOK))
modules/pam_cracklib/pam_cracklib.c:	    if (getuid() || (flags & PAM_CHANGE_EXPIRED_AUTHTOK))

Above all it involves the pam_unix module which is the STANDARD/DEFAULT pam module!

What does it matter?

For example for pam_unix the missing PAM_CHANGE_EXPIRED_AUTHTOK flag in the lightdm code
causes the activation of another pam flag (UNIX__IAMROOT [1]) which causes unexpected behaviours [2].

You can verify this on Wheezy (and probably on Ubuntu):

1) install lightdm
2) create a new test user (call it "giulio", set password "giulio")
# adduser giulio
3) login with giulio and try to change the account password
giulio$ passwd
try to use the password "t", it fails because it's too short
try to use the password "turetta", it fails because it's too simple
password change succeeds only with an (almost) secret password like
"tuREtt4"
3) now expire giulio's password
# chage -d 0 giulio
4) try to login by lightdm, current password is "tuREtt4"
5) login succeeds but you will be asked to insert a new password, insert "t"
6) giulio's password is now "t"! Ouch!!!!
7) now, expire the password again and try to change it to "a" by a login
with gdm3 (ssh, console, ...): the right policies will be enforced

Note, about pam_unix, that this bug also breaks the "remember" pam_unix
policy and the "obscure" policy.

I think that this bug probably impacts most of the pam modules and so it
must be considered an important security issue (security policies are
not enforced).

I'm performing further checks...

[1] from Wheezy pam source: /pam-1.1.3/modules/pam_unix/support.c:68
if (getuid() == 0 && !(flags & PAM_CHANGE_EXPIRED_AUTHTOK)) {
  D(("IAMROOT"));
  set(UNIX__IAMROOT, ctrl);
}

[2] from Wheezy pam source:
/pam-1.1.3/modules/pam_unix/pam_unix_passwd.c:491
if (off(UNIX__IAMROOT, ctrl)) {
  if (strlen(pass_new) < pass_min_len)
    remark = _("You must choose a longer password");
  D(("length check [%s]", remark));
  if (on(UNIX_REMEMBER_PASSWD, ctrl)) {
    if ((retval = check_old_password(user, pass_new)) == PAM_AUTHTOK_ERR)
      remark = _("Password has been already used. Choose another.");
    if (retval == PAM_ABORT) {
      pam_syslog(pamh, LOG_ERR, "can't open %s file to check old passwords",
                                        OLD_PASSWORDS_FILE);
      return retval;
    }
  }
}