Inheriting from contracts of a different Solidity version

It is acceptable.

Some things to understand and clarify.

There is only one compiler version and it will apply to the top-level contract and all inherited contracts. A style I have found useful is

• a specific version in the pragma of the top-level contract to disambiguate the version and reduce confusion during review, test and verification (e.g. etherscan). It is useful to know, from the code, what version of the compiler must have been used to compile it.
• an ambiguous pragma in the inherited contracts, because you will know the precise version will be determined at compile-time and it must be the version specified in the main contract.

Ambiguous (convenient - unmodified openzeppelin contracts):

pragma solidity ^0.6.0;

contract Component {}

Unambiguous Top-level contract:

pragma solidity 0.6.6;

contract Main is Component {}

There is no doubt that Main must be compiled with 0.6.6 and, by extension, so is Component because inheritance is a source code roll-up and because it is part of Main.

The scheme works well for large systems with many contracts and components. As the developer, if you change your mind and want to go with a newer compiled (e.g. 0.6.10) you will only change a few top-level contracts and run your tests.

Hope it helps.

Update

Some code auditors favour explicit pragmas at every level so it might be productive to follow the suggested scheme during development and then make the sub-modules precise, as well when polishing a candidate production release.

If the contracts compile they should work without problems.

Usually both Solidity and OpenZeppelin try to maintain compatibility between minor version of the same release.