A somewhat related issue involves casting. Consider these questions:
Can I cast a deterministic object to System.Object?
If so, is it reference counted?
If the answer is yes, everything is reference counted.
If the answer is no, the object loses determinism.
If the answer is "error," the fundamental premise that System.Object is the root of the object hierarchy has been violated.
By now, you should be seeing just how complex this issue is. If a deterministic object implements interfaces, is the reference typed as an interface reference counted? If the answer is yes, you reference count all objects that implement interfaces. (Note that System.Int32 implements interfaces.) If the answer is no, once again the object loses determinism. If the answer is "error," deterministic objects can't implement interfaces. If the answer is "it depends on whether the interface is marked deterministic," you have another bifurcation problem. Interfaces aren't supposed to dictate object lifetime semantics.
What if someone implements an API that takes an ICollection interface, and your object that implements it needs determinism, but the interface wasn't defined that way? You'd be out of luck. In this scenario, two interfaces would need to be defined-one deterministic and one nondeterministic-with each method being implemented twice. Believe it or not, a means of automatically generating the two versions of the methods was also considered. That line of thought bogged down in immense complexity, and the idea was dropped.