Is there an existing issue for this?

• I have searched the existing issues
• I have read the guide to filing a bug

Use case

Preface: I am aware of @rrousselGit's previous #107112 PR and the reasons as to why it wasn't accepted. As many have outlined, merging the reactivity/listen-ability with inherent dependency removal is an inherently risky path to tread on, which can introduce more problems than it can solve down the line.

That doesn't, however, make the absence of removeDependency to complete the current set of update, get, set and notify methods, any less tolerable. Not having a basic remove makes the whole set virtually useless for any cases more complex than trivial, as in using a ValueNotifier that only allows to get, set, and notify its listeners, but never to remove any of them.

Any logic on the side of InheritedElement which involves keeping track of dependencies separately, for any reason dictated by an appropriate use case, as it currently stands:

class CustomInheritedElement 
extends InheritedElement {

  CustomInheritedElement(super.widget);
  final Map<Tracked, Set<Element>> _tracked; 

  // get, set, update, and so on
}

Requires forceful iteration over the whole structure on each and every minor change to determine whether the tracked Elements are still properly mounted or not and can be safely notified via didChangeDependencies(), as needed.

Proposal

Given the previous comments and no particular objections to the remove itself - recognized as an issue by the core team, and acknowledged as one that must be fixed, I'd like to get a green light on the potential merge of the removeDependency PR only, with no additional gimmicks and "nice-to-have"-s.