For small public exponent e, private exponent d should be less than but close to modulus n.
Is there any particular test, applied in common implementations, to verify that? If so, what would be the threshold?
I have noticed that using Python's Crypto.Util.number.getStrongPrime (docs):
key_size = 2048
prime_size = int(key_size / 2)
e = 65537
p = getStrongPrime(prime_size, e)
q = getStrongPrime(prime_size, e)
the bit length difference between d and n is never bigger than 6.
The private exponent $d$ is generally constructed as $d = e^{-1} \bmod \varphi(n)$. Is means it is the smallest positive integer that satisfy $e \equiv d \pmod{ \varphi(n)}$, and in particular $d < \varphi(n)$, which is the upper bound.
Another view of this is that there exists an integer $k$ such that $$ ed = 1 + k\varphi(n), $$ The integer $k$ is at least $1$ and we can get a lower bound for $d$: $$ d = (1 + k\varphi(n)/e \geq (1+\varphi(n))/e. $$ Then, we can say, roughly, that $d$ is expected to be an integer between $(1+\varphi(n))/e$ and $\varphi(n)$.
Of course, it shall be noted that adding a multiple of $\varphi(n)$ to $d$ gives a valid private exponent, and those are bigger than $\varphi(n)$ (and makes the computation more costly).
Is there any particular test, applied in common implementations, to verify that private exponent $d$ is less than but close to modulus $n$ ?
Yes, for some lenient definition of close. FIPS 186-4 is a de-facto standard that some implementations follow. It prescribes$$d\gets e^{-1}\bmod\bigl(\operatorname{lcm}\left(p-1,q-1\right)\bigr)\tag{1}\label{eq1}$$which implies $d<p\,q/2$ thus¹ a $d$ at least one bit less than the modulus is. And in the end of FIPS 186-4 appendix B.3.1 additional criteria 3 lies the prescription:
In the extremely rare event that $d\le2^{nlen/2}$ (where $nlen$ is the bit size of the public modulus), then new values for $p$, $q$ and $d$ shall be determined. A different value of $e$ may be used, although this is not required.
Such test is pointless from a theoretical standpoint when both:
Condition 2 should always hold for a proper RSA key generation procedure. Even if $p\bmod e$ and $q\bmod e$ where fixed public constants, condition 2 could still hold for truly small $e$ including $e=65537$, up to at least say 20 bits: revealing that little information about $p$ and $q$ appears unlikely to ease factorization.
The only technically sound rationale for $d\le2^{nlen/2}$ or other test against small $d$ is to prevent the import of an inappropriately generated private key; and in an otherwise proper RSA key generation procedure with modulus bit size $nlen\ge1024$ (the minimum in FIPS 186-4), to catch a malfunction or a bug.
In a fielded security device (Smart Card, HSM), if that test fails at key generation, the Right Thing is to fall into a safe state where the gizmo needs at the very least to be physically reset before anything else goes, perhaps after metaphorically falling on one's sword, that is burninating/zeroizing all secret material. In code under development, that test should be an assertion. If something needs to be rubber-stamped, do whatever is morally defensible to satisfy the authority with the rubber-stamp.
I have noticed that using (strong primes per some criteria) the bit length difference between $d$ and $n$ is never bigger than $6$.
It was not tried hard enough, or something is broken in the key generation procedure. There is no good reason why that would hold for $e=65537$. That's even though, contrary to $\eqref{eq1}$ mandated by FIPS 186-4, $d$ is computed per $$d\gets e^{-1}\bmod\bigl((p-1)(q-1)\bigr)\tag{2}\label{eq2}$$ As explained in that other answer, $d$ per $\eqref{eq2}$ is expected to be roughly uniform in the interval $\bigl[(1+\varphi(n))/e,\varphi(n)\bigr)$ and we should sometime see it near the bottom, thus with 15, perhaps 16 bits less than the public modulus. However we need to perform about $e$ attempts to approach that limit.
If the test against $d\le2^{nlen/2}$$\eqref{eq1}$ is used, that should be with $d$ per $\eqref{eq1}$. Absent error, that test mathematically can't fail for $d$ per $\eqref{eq2}$ with $e<2^{256}$ and $n>2^{1023}$ as mandated by FIPS 186-4. Failure of the test is at least theoretically possible when using $\eqref{eq1}$, should $\gcd(p-1,q-1)$ happen to be huge. Which is extremely unlikely for proper generation of $p$ and $q$.
Both $\eqref{eq1}$ and $\eqref{eq2}$ are allowed by PKCS#1 since the origin, thus $\eqref{eq1}$ is unlikely to cause an interoperability problem even if a private key is moved across implementations (which should be the only case when the method used for the determination of $d$ matters, since all mathematically valid $d$ for a given public key produce the same numerical results when properly used in RSA). Contrast with the use of $\eqref{eq2}$ which has fair probability to lead to failure at key import by an implementation written with FIPS 186-4 as a reference.
¹ By definition of $e^{-1}\bmod\lambda$, and given that $\lambda=\operatorname{lcm}\left(p-1,q-1\right)$, and given that primes $p$ and $q$ are large, thus $p-1$ and $q-1$ both are multiple of $2$.
