Polymorphism on DDD aggregates

I am designing my domain model and am having trouble understanding how to search for similar aggregates with the same id.

Lets say we have two aggregates ActiveEmployee and InactiveEmployee. They hade many differences in their structure but also some commonalities since they are both Employees and they both have an employeeId.
They each have a separate repository with a findById and in some cases I need to retrieve them separately but in some cases I need to search for an Employee and later see if the Employee I got was Active or Inactive.

I first thought of having some abstract class Employee with its own repository to do the search but from what I have read aggregates should not use this type of polymorphism. By having two separate repositories I need to handle checking both repositories whenever I need a general employee and handle the cases where I do not find any in one or both of them.

Is there some best practice that can be used in this situation?

Edit:
I realize that the above situation may not fully express my problem so lets try this:

I have two types of packages, ProvidedPackage which can not be changed and UserPackage which is created and changed by the user.
Both contain Modules and the user selects what modules are needed from several different ProvidedPackages and other UserPackages to create a new combined package. The source package of each module is also stored in the new UserPackage for tracing purposes.
ProvidedPackages contain some Rules for how the specific instance modules can be used which the UserPackage does not have. And UserPackage has an approval field that ProvidedPackage does not have. (There are also other differences between them).
When a new package is created the user adds modules from both package types and does not care if it is a ProvidedPackage or a UserPackage.

My thought for solving this is to have two separate aggregates since there are many differences in invariants. A "PackageID" is used as the identity for both types. It feels like a parent class "Package" would be good for situations where I need to retrieve packages using a list of PackageIDs. Otherwise I always need to check both repositories each time. And if future package types are added more checks need to be added.

In the specific case of active and inactive employees, I really don't think they should be treated as different aggregates: every employee will become inactive at some point, after all. By modeling them as separate aggregates, you are, strictly speaking, throwing away the ability to ensure that a given ID is not simultaneously active and inactive.

Having very different state models for active and inactive employees suggests that those aggregates mostly live in different bounded contexts. You'd have an Employment bounded context which is responsible for assigning IDs and tracking whether an employee is active or inactive (this could be accomplished with employeeStarted and optional employeeFinished fields) and perhaps other common aspects of the model. In contexts where it only makes sense to deal with active employees (e.g. Payroll), you have a command to terminate employment (which might in turn delete from the repository for that bounded context).