This isn't a design goal of Helm, and continues to not be. It is not within Helm's purview to manipulate objects that were not created by Helm, or to disregard out-of-band changes to objects under its "control" - this is a feature that makes Helm compatible with other systems that may change manifests, and makes Helm safe to use. Remember that it is a YAML rendering system, not a configuration management system like Puppet or SaltStack. It does not "enforce" configurations.
If you wish to accomplish the behavior you describe, you could delete the objects in question prior to re-creating them with Helm. You can potentially use Kubernetes namespaces to accomplish this reliably by giving each chart its own namespace, and deleting the namespace prior to chart installation as a form of "hard reset".
Or keep those users who are used to editing manifests with
kubectl from doing that, and instead direct them to pushing those changes into charts or values. It doesn't seem reasonable to discard their changes if they needed to be made - this is exactly why Helm performs three-way merge operations on manifests to begin with. I understand the desire to persist configuration in a single point of orchestration, but don't expect to accomplish this by not using of a single point of orchestration.
This problem comes up consistently when applying higher level orchestration practices to teams that are accustomed to lower level orchestration methods, and is in no way conceptually constrained to Helm. Helm is good at handling the situation gracefully by performing merge operations, but results in a functioning mess of orchestration methodologies (at least it doesn't break things or simply fail). Start by not making the mess, or constraining the mess to a scratch environment and scooping it up into Helm charts for production.