It doesn't seem to be a separate fingerprintability vector. Entry guards act as a client's directory guards by default:

UseEntryGuardsAsDirGuards 0|1

If this option is set to 1, and UseEntryGuards is also set to 1, we try to use our entry guards as directory guards, and failing that, pick more nodes to act as our directory guards. This helps prevent an adversary from enumerating clients. It’s only available for clients (non-relay, non-bridge) that aren’t configured to download any non-default directory material. It doesn’t currently do anything when we lack a live consensus. (Default: 1)

I am afraid it is a fingerprinting vector in some cases. The critical part is the following:

and failing that, pick more nodes to act as our directory guards

So let's say fetching the consensus from the entry guard failed for some reason(*), an additional directory guard will be picked. Then it's some entry guard a plus some directory guard b. Now going to another location and connecting to both relays should be fingerprintable.

(*) Perhaps adversaries could specifically block downloading the consensus from the entry guard only but let through all other traffic.

However, out current instructions should implicitly cover it.

• Alternating Bridges
• Fresh Tor Entry Guards by regenerating Tor State File
• Always Non-Persistent Entry Guards

Any of these should cover the directory guards also. Does that make sense?

(*) Perhaps adversaries could specifically block downloading the consensus from the entry guard only but let through all other traffic.

The only way that could happen is if your guard is malicious but then there are bigger problems to worry about.

A bridge acts as a directory guard (to bypass censoring of this data requested by the clients).

However, out current instructions should implicitly cover it.

Agreed.