As the other answer stated, no, passing tests on 2 non-conflicting branches are not enought to say there won't be failures after merging them both. You have plenty of examples.
Let me focus on the second part of the question, the proposed flow, how it may fail and how it might be approached:
- When a pull request is made, run the unit tests to catch anything egregious.
- Have conversations, code reviews etc...
- Once the pull request is ready to be merged, do a test merge into master, run the unit tests, if all succeeds, commit the merge.
This is a nice and sound process and perhaps a great one for a small project. It really ensures no failures in master, and it's quite simple. There is one big issue with it: it doesn't scale. It doesn't scale at all.
With this process you drafted you must serialize the commits, and this gets very costly very fast when the project grows.
For instance, if you have 3 pull requests, you need to test-merge the first one, run all the tests, then update master. Only then you can start testing the test-merge of the second branch, and only after it's in, you can start running the proper tests for the last branch.
This means that if your test suite takes 3 minutes, you can make at most 1 commit in every 3 minutes. That's inconvenient, but feasible. However, if your test suite takes 10 minutes, you are limited to 6 merges per hour at best, 48 merges per work day. A team of 20 people working with such a constraint would spend half their time babysitting the pull requests, and you could end up with a typo fix waiting half a day to be merged.
Worse yet, if your test suit take several hours and you have many thousands of developers working on a single monorepo, producing tens or hundreds of commits per minute... well, you see the problem. Even running the continuous integration after every merge makes little sense in this case.
What is more scalable?
Focus on the continuous integration and quick rollbacks instead of preventing all bad merges from happening. Also track the test failures, so that you can guess with high confidence whether a test failure is caused by the branch, or by the broken master (a smart enough testing tool will annotate them as "already failing", and you may vote to allow merging with this kind of failures). You don't even need to run the integration after each merge (it's the simplest starting point, but doesn't scale to the really huge projects), it may be every few minutes or every hour, depending on how much resources you want to throw at it.
If you detect no failures, everything is fine. If you detect a failure, you can run a binary search over the changes to determine which one caused the specific test to fail - this is relatively cheap, because usually you won't have half the tests fail, just a handful of them.
On top of that, leverage your build system in order to determine the set of builds and tests that actually may be affected by each change, and limit the required test suite to these. Also, as part of CI run these selected tests immediately after the merge, in order to detect the issues as quickly as feasible (separately from the full test suit running once in a while). The determination doesn't have to be watertight - in case you miss a test that is actually affected, the "big" integration testing will still catch it, just a while later, but most of the time you'll get the feedback quite fast.
The flow I described is loosely based on what Google does internally, I assume it's similar to what other big companies do as well. It's worth pointing out that no popular VCSs supports the monorepos as big as theirs, at least not the vanilla version.
In case of Google, the VCS is Perforce based, and it has much stricter rule for conflicts - any other change in the same file is a conflict, no matter how close or far apart are the changes. This eliminates quite a bunch of pitfalls, like those with removed imports - the change would have to be updated and rebuilt, and the issue would show up, similarly to the process you proposed. So this is one more counter-measure - just tighten up the rules for what can be merged to the master. While requiring "only fast-forward changes with passing tests" (i.e. your proposed rule) is unfeasible at scale, "only changes that are fast-forward with regard to affected files" can scale up relatively well.