If you add B and C as submodules in A, their .git files will be saved in .git / modules / B and .git / modules / C. Each of them (after you did git submodule init; git submodule update in each) will have its own .git / modules / D, however repo files will not be shared. Each of them will have its own extracted copy of the files.
You can get around these issues with symbolic links. For example, you can add D as a submodule only to B, and then designate BD in C. Now you can work in either B / D or C / D, and in the other, synchronously. However, there are two problems with this. Firstly, you cannot check different points in each - they must remain in sync, because they are one and the same. This is insignificant, but may even correspond to your wishes. The second is worse; if you track D only in B, and C "tracks" it only through a symbolic link to BD (symbolic links are understood through git, btw), then C is not able to control its own dependency on D.
It's okay to make changes to the submodule and then check this change in the dependent containing the repo, but now you have to remember to switch to another repo in the diamond and make sure it works too (automatic testing - especially if you skip through git hook - can help a lot here). If you return the commit to B / D, for example, or look at an older one, or switch branches to B / D, you should always switch to C / D and make sure that it still works there. This setting can be a bit of a pain with micromanagement, prone to broken commits, where B works against the current D, but C doesn't mean, or vice versa.