The way (shared) secure strings work now is that when "hej" is turned into a secured string, the string object "hej" in the shared string pool gets marked as "secure". This object is referenced by all strings "hej", secure or not. The flag remains on the string object until it all references to "hej" are gone and the string object is freed (at which time the actual string is zeroed over, this is the "secure" feature).
The fact that also non-secure strings can refer to the same string object means that the string can remain longer in memory (before being zeroed over) than if it had only secure references to it, but actually it makes no difference. Consider the case that there is one non-secure reference to "hej", and one secure, which has just been removed.
Case 1, shared secure and non-secure strings: The secure shared string "hej" remains in memory because it still has a (non-secure) reference. Total counts of "hej" in the process space: 1.
Case 2, non-shared secure and non-secure strings: The secure shared string "hej" has been zeroed over because it has no more references. The non-secure string "hej" still remains because it has a reference. Total counts of "hej" in the process space: 1.
So it is clearly the case that not sharing the strings does not reduce the visibility of the secret string in the process space. In the same way, if making a string secure would also move it to non-pageable memory (which might be good), making the string not shared would not reduce the visibility of the secret string in the swap partition. It would rather be the other way around.