I can't leave a comment on you're post so I'll say here:
This is a known problem and one that I have also. I haven't found any way to fully resolve this issue and haven't seen any recent solutions. You can see my post hereto ensure the issue is in line with yours.
The only solution I've seen so far is described here in a msdn blog from '11. It identifies the problem in the Silverlight Framework and he provides a workaround which I implemented. Include the class file in your project and make use of the XAML tags, and it will allow your contextmenu keep in sync with the parent's datacontext. I've ran into a small side-effect using it, so it's only a band aid.
I also found tell from another forum that it's a known issue with no solution, but a patch may be found at codeplex here. My issue with the patch is I couldn't figure out how to implement it, and also the LLS (which is what I'm using the ContextMenu with) has migrated directly into the SDK, so I was stuck.
That's all I've dug up on the problem, hope it helps. If someone else has anymore to add please do.
Update: Using some of what was in the above provided links, I think I have a slightly better solution. In the ContextMenu Unloaded event, refresh the view. Something like:
private void add_but_up(object sender, RoutedEventArgs e)
{
ContextMenu conmen = (sender as ContextMenu);
conmen.ClearValue(FrameworkElement.DataContextProperty);
}
This is essentially what the patch in the blog does. Only in a completely different context. So my issues were an inability to use functions like ScrollTo(). Doing this in the code behind of the actual page seems fix the ContextMenu binding issue.