I maintain axios-response-mock which covers a similar use-case as does axios-mock-adapter.
My lib broke with axios version 1.2.0 with regard to passthrough requests; I got runtime errors in the vein of 'originalAdapter is not a function'.
I finished analysing the issue and thought I let you know what I found out; because I'm quite sure it broke your lib in the very same way.

The following section contains my analysis and thoughts.

Analysis

• in axios v 1.1.3 (and below) the original default adapter is a function
• (in axios v 1.2.0-alpha.1 the original default adapter is still a function)
• in axios v 1.2.0 (and above) the original default adapter is an array ['xhr', 'http']

the change was introduced with #5277
(Changelog entry: refactor: allowing adapters to be loaded by name #5277)
(merged November 22nd) and released with v1.2.0 on November 22nd

If a custom adapter now wants to selectively decide which requests to handle itself and which requests to passthrough to the default adapter / delegate to the default adapter, how best would it now obtain a reference to the default adapter?

Before the change, a custom adapter could secure a reference to the default adapter via axiosInstance.defaults.adapter and call it later to delegate.

Example:

this.originalAdapter = axiosInstance.defaults.adapter;
axiosInstance.defaults.adapter = this._processRequest.bind(this);

// and later
if (matchedRoute)
    return this._respond(matchedRoute, config);
else
    return this.originalAdapter(config);

I opened a discussion on the axios github repo.

What options do I have now?

• re-implement and ship my own xhr and http adapter? no, not feasible.
• import the axios v1.2.0 xhr and http adapters and include in my library bundle? could work. would only consider this as a temporary solution
• refactor response-mock implementation to work in two separate steps: custom interceptor to check if a mocked route matches, and if that's the case add mock adapter to the options, which means all non-matching routes are handled normally. This is an elegant solution, but I would prefer a pure adapter approach as soon as axios adds a feature to delegate to the default adapter.

Conclusion:

• branch from current master
• try out if I can actually reference and bundle the xhr adapter from axios v1.2.0
• publish as 0.2.2-alpha.1
• share my findings with https://github.com/axios/axios and https://github.com/ctimmerm/axios-mock-adapter

Today I published version 0.2.2-alpha.1 of axios-response-mock and it seems I could fix the issue. But it is only a temporary stopgap.
When axios starts supporting a stable way to obtain a reference to the defaultAdapter I will change my fix; if the axios maintainers dismiss the feature request I will probably refactor my lib into the two steps approach sketched above.