Deinstance Keyframes

Hi,
Is there any way to remove keyframes from deinstanced values of a node?
By pure logic, keyframes of deinstanced values SHOULD be ignored, but they aren't. If I animate a value, create an instance of the node and deinstance this value, the keys still persist in the instanced node. Deleting the keys there result in also deleting the keys in the original node, what I don't want...
That said, I can't deinstance a keyed value even if it shows up as deinstanced in the inspector.

So what you're saying is that even though the animation is deinstanced, the actual animation isn't?
Can you give a concrete example of how to reproduce this?

No, I deinstanced the value - which doesn't have an effect to the animation itself. I just discovered that I have to right-click the value, deinstance it and then also have to "remove...[whatever is animated]". This will remove the animation only from the instance but not from original.
It makes no sense to me, to keep the keyframes of a deinstanced value in sync - but that's my personal opinion. Maybe there's actually a reason for this behaviour.

To reproduce, just create an ellipse, add a key for "Level" at frame 0. Then create an instance of the ellipse, deinstance "Level", go to any other frame and change the "Level" value. The original will also get the new key at this frame unless you "remove Ellipse1Level".

You're right. I would consider this a bug or at the very least unexepcted behaviour.

It's because the animation spline is actually a hidden Modifier. Deinstancing unlinks the input, but it retains its connection to the invisible external tool, which is still common between the two. It's a subtle and non-obvious behavior, but it's not a bug. Could definitely be better documented. As far as I know, the only place it's described is in the Scripting Guide, in the little mini-tutorial on how to animate an input with a script.

It's at least a little more apparent if the input you've animated is a Point control, which creates a visible Path modifier.

The strange thing is that if you copy/paste an animated tool you get a *new* hidden modifier, don't you?
So there it isn't connected to the original spline. Which would be sort of logical to me, because especially if you connect something to something else, you do this so you can use one value to drive multiple values so the fact that it creates a duplicate that's no longer connected is in that sense also unexpected behaviour for people who haven't been dealing with Fusion's idiosyncracies since Windows NT4.
Even though it's technically correct, I still feel the OP has a point.

The strange thing is that if you copy/paste an animated tool you get a *new* hidden modifier, don't you?

Correct. Copy-paste of a tool creates a copy of the modifier with a unique name, but pasting an instance does not—the new tool will have the same modifier, not an instanced one.

It's behaving as designed. It's a matter of opinion whether or not the design is bad. Personally, I think the best change would be to make the animation spline visible in the Modifiers panel, although that would risk clutter. Maybe there could be an option in the prefs to turn it off. That would go some distance toward helping users understand what's happening while not breaking legacy comps and habits.

It's the same as having any other tool connected to an input. If you had a BG connected to a BC and a CC, changing the BG values would affect both the CC and BC even though they aren't instances of each other. So yeah, this is consistent with how Fusion works, it's just that without seeing the modifiers in the flow, you don't notice that you're affecting one tool which outputs to two independent inputs.