Although this is contained in #1725, I'm going to try to distill this down to exactly the feature I want, plus the context for why I want it.

This issue originates in an interaction between marshmallow-oneofschema ("oneofschema") and marshmallow-sqlalchemy. Both of these are important to marshmallow, especially since oneofschema is the go-to answer for questions about polymorphic fields.

oneofschema overloads load and dump with special operations. This works for most simple use cases, and most features (e.g. partial, many) are supported.
However, it means that oneofschema doesn't support pre- and post-processing hooks built into marshmallow, and the only way to support them in the current implementation, in which oneofschema replaces load and dump, is to reimplement the marshmallow load and dump logic.

Looking into options for this, _serialize and _deserialize are in exactly the right place for oneofschema to overload them with its specialized behavior. As proven in marshmallow-code/marshmallow-oneofschema#130 , the result is smaller code for oneofschema with added support for hooks.

It seems a perfect fit. However...

In marshmallow-code/marshmallow-oneofschema#111 , oneofschema added support for passing through additional keyword arguments from load and dump to its child schemas. The reason is that marshmallow-sqlalchemy also customizes load and dump, but in a different way. For that library, additional arguments control added behaviors.

If oneofschema starts using _serialize and _deserialize, it will lose the ability to support the marshmallow-sqlalchemy use-case.

If marshmallow wants to support oneofschema in this, I believe it would be best to consider _serialize and _deserialize part of the public interface for the purpose of subclassing and customizing schemas. The parallel with these method names for Fields already suggests them as semi-public.

The most naive approach would be to allow arbitrary keyword arguments to load to go through _do_load and down to _deserialize (and likewise for dump). However, that allows load to accept and ignore arbitrary arguments like parttial=True -- it makes the experience for users worse.
In #1725 I proposed a specific argument, extra, a mapping which exists only to support extensions like oneofschema. I'm open to other approaches. A major version of oneofschema, but not of marshmallow, would be needed to implement the change.