it is discussed by intro(5):

			... The qid
          represents the server's unique identification for the file
          being accessed: two files on the same server hierarchy are
          the same if and only if their qids are the same.  (The
          client may have multiple fids pointing to a single file on a
          server and hence having a single qid.)  The eight-byte qid
          fields represent two four-byte unsigned integers: first the
          qid path, then the qid version. The path is an integer
          unique among all files in the hierarchy.  If a file is
          deleted and recreated with the same name in the same direc-
          tory, the old and new path components of the qids should be
          different.  Directories always have the CHDIR bit
          (0x80000000) set in their qid path.  The version is a ver-
          sion number for a file; typically, it is incremented every
          time the file is modified.

it's quite important that Qid.path be unique for active
files in the same hierarchy (identified by type and dev),
otherwise bind and mount will malfunction because they ultimately
depend on Qid values via the mount table.  for that reason,
exportfs(4) resolves qid.path clashes that can occur when it
exports a hierarchy with binds and mounts within it.
(the importing system will expect Qid.path to be unique
in the hierarchy it sees, but the original type and dev
that separated the Qid.path spaces on the exporting system
are not seen on the importing system.)

Qid.vers is less critical but is used by the kernel
file cache for mounted file systems, and by cfs(4) and others.
devices often don't maintain it; support elsewhere is a little patchy,
but kfs and the file server kernel do support it, as does env(3).