The short answer is no.
I'll assume $SHA256_d(M)$ is $SHA256(M)$ when $d=0$, else $SHA256(SHA256_{d-1}(M))$.
$SHA256_1$ is protected against length extension attacks.
The only sizable benefit that I see in parameterizing $d$ is that it allows tuning a slow down of the computation intended as a protection against brute force attacks. However there are more flexible primitives for that purpose, like PBKDF2 or Scrypt, and Scrypt is considerably safer for similar slowdown.
Leaving $d$ unknown to improve security is almost pointless. An adversary can have a rough figure about $d$ by a variety of side channels, e.g. duration of the computation. And an adversary knowing $SHA256_d(M)$ but neither $d$ nor $M$ is annoyed by a factor of less than 4 by not knowing $d$ if she knows that $M$ is in her dictionary. She does as follows:
- Chooses a small starting $n>0$ per some guess of $d$, or just $n=1$.
- Computes $SHA256_n(X)$ for all the $X$ in the dictionary, comparing the known $SHA256_d$ with the $SHA256$ obtained at each of the $n$ steps, proclaiming success (with high probability) if there is a match.
- Having ruled out all values of $d$ up to $n$, she doubles $n$ and continues at 2.
If she happens to have enough memory (as much as needed to store as many hashes as entries in the dictionary) she can store the last result obtained for each entry at step 2, and reuse that later; the penalty falls to a factor of less than 2. Update: further, with the same memory, increasing $n$ by $1+\lfloor Log(n)\rfloor$ at step 3 makes the penalty factor become arbitrarily close to 1 as $d$ grows (this can be tuned-up for low $d$ by changing the constant and the base of the logarithm).
