Like you said, really strange.
Ok, so I'm going to provide a lot of details here on how duplication works and I'm making this public so feel free to link to it.
What Controls Folder Duplication?
Folder duplication in StableBit DrivePool is fundamentally controlled almost entirely by our covefs.sys pooling file system driver. Reading duplication levels and setting duplication levels on folders is not "cached" (or remembered) by the service in any way. So resetting the service or reinstalling should not affect folder duplication. Duplication levels are however cached by covefs. The reason why it works like this is because covefs needs to know the duplication level of any file on the pool, in real-time, as those files are created. Because of this requirement, it makes sense to have the code to efficiently read / cache and update the folder duplication level in one place, in the kernel, and have the service interact with that code.
Incidentally, this is the same interaction that's available from the dpcmd command line utility. It doesn't read / write the duplication level, instead, it sends special commands to the pooling file system driver (covefs) to change the duplication level.
How is the Folder Duplication Level Stored?
Each folder on the pool, can conceptually have a duplication level associated with it. For example, it can be x2, x3, etc... That duplication level is stored in an alternate data stream on the folder itself.
For example, a pool part folder will have the following alternate data stream:
PoolPart.305d6edd-5f99-4c5e-9fa2-456d6d6fb5b3:DuplicationCount.Tag.CoveFs
You can actually open this up in notepad like this:
D:\>dir /a /r
Volume in drive D has no label.
Volume Serial Number is BE55-251F
Directory of D:\
...
12/17/2015 05:10 PM <DIR> PoolPart.305d6edd-5f99-4c5e-9fa2-456d6d6fb5b3
4 PoolPart.305d6edd-5f99-4c5e-9fa2-456d6d6fb5b3:DuplicationCount.Tag.CoveFs:$DATA
48 PoolPart.305d6edd-5f99-4c5e-9fa2-456d6d6fb5b3:PoolId.Tag.CoveFs:$DATA
...
1 File(s) 0 bytes
7 Dir(s) 664,052,600,832 bytes free
D:\>notepad PoolPart.305d6edd-5f99-4c5e-9fa2-456d6d6fb5b3:DuplicationCount.Tag.CoveFs
For a root directory (which this is), you will see the level set to MI.
Both M and I are special tags.
- M - Sub-folders may have a different duplication level than this folder (this is an optimization so that we don't have to crawl the entire pool every time)
- I - Indicates that this folder is inheriting its duplication level from the parent folder (in the case of a root folder, it's an imaginary folder x1 above it)
In the case of a x2 duplicated folder, the level may be simply indicated as 2. Now I really don't recommend editing these tags by hand. While they appear as ASCII, they are actually read as binary data and the special handling of M and I tags has to be correct. However, it's ok to delete these tags and let the system rebuild them if something goes very wrong with the directory structure of a pool part (such as file system directory index corruption).
Which leads us into...
How are Duplication Tags Repaired?
Every time the StableBit DrivePool background service starts up, it does a scan of all of the duplication tags on the pool and ensures that each one is "consistent". This process is intentionally separate from what the file system already does because it checks each pool part individually for consistency with all of the other pool parts on the pool.
If it finds an inconsistency, such as a duplication tag that's missing or incorrect, it will automatically repair all of the tags falling back to the highest duplication level detected in the case of a conflict.
So that's in a nutshell how the entire folder duplication system works, not considering file placement, which works alongside it. I'm not entirely sure what's going on here, but it seems to me quite clearly that the duplication tags on those folders contain an incorrect level. If that's the case, this should be confirmed, and the information provided here can hopefully be of some help in that regard.