As pointed out here and here, XSD's limitation of having one target namespaces per file makes your "semantically equivalent" request impossible to solve. This is true, and also typical, in all scenarios where the namespace itself is used to define boundaries of (or refine) semantic sets.
For one time or design time refactoring, where you don't have to programatically deal with such a thing in a recurrent way or dynamically, you may also try to take a look here; Maybe the issue in your case is not that the imports are not supported (which I would find strange) but rather that the complexity of the include/imports makes the graph too complicated for your tooling. As shown in the latter post, by collapsing the includes, with a net effect of reducing the number of required imports, the problem was solved.
Alternatively, if somehow your "semantic equivalence" doesn't involve namespaces (for e.g. I've seen people that were rather interested in developing a relational model from XSD), it may be possible, through refactoring, to bring all namespaces into one (or none i.e. no target namespace) and then feed it to your tool. The only catch here, from an automatic refactoring perspective, is to ensure that there are no duplicate named XSD components across different namespaces; e.g. can't have same name for an element, or type, or attribute, or group, etc. in different namespaces.