0.3.0.x dir auths enforcing ED identity keys: intended?

Check out the 'atlassky' relay. n-1 dir auths are voting about it because they find it to be Running. (I think it is Running.)

But moria1 is voting only V2Dir, and no other flags. That seems to come from:

Dec 29 12:21:44.517 [info] channel_tls_process_versions_cell(): Negotiated version 4 with 176.123.26.11:80; Sending cells: CERTS
Dec 29 12:21:44.517 [info] connection_or_client_learned_peer_id(): learned peer id for 0x7f97d5d688f0 (176.123.26.11): 848878591CAF51274E3A9B71933E9599FA39E122, <null>
Dec 29 12:21:44.517 [info] dirserv_orconn_tls_done(): Router at 176.123.26.11:80 with RSA ID 848878591CAF51274E3A9B71933E9599FA39E122 did not present expected Ed25519 ID.
Dec 29 12:21:44.517 [info] channel_tls_process_certs_cell(): Got some good certificates from 176.123.26.11:80: Authenticated it with RSA
Dec 29 12:21:44.517 [info] channel_tls_process_auth_challenge_cell(): Got an AUTH_CHALLENGE cell from 176.123.26.11:80: Sending authentication type 1
Dec 29 12:21:44.517 [info] channel_tls_process_netinfo_cell(): Got good NETINFO cell from 176.123.26.11:80; OR connection is now open, using protocol version 4. Its ID digest is 848878591CAF51274E3A9B71933E9599FA39E122. Our address is apparently 128.31.0.34.

From the new code in dirserv_orconn_tls_done(), I see

    if (! ed_id_rcvd || ! ed25519_pubkey_eq(ed_id_rcvd, expected_id)) {
      log_info(LD_DIRSERV, "Router at %s:%d with RSA ID %s "
               "did not present expected Ed25519 ID.",
               fmt_addr(addr), or_port, hex_str(digest_rcvd, DIGEST_LEN));
      return; /* Don't mark it as reachable. */
    }

So it looks like the dir auths are now enforcing whatever ED key they saw from the relay earlier? Is this change intended at this point? If so, is there anything we need to do to explain to current relays what they need to do or not do?