The concept you initially refer to in your question is called covariant return types.

Covariant return types work because a method is supposed to return an object of certain type and overriding methods may actually return a subclass of it. Based on the subtyping rules of a language like Java, if S is a subtype of T, then wherever T appears we can pass an S.

As such it is safe to return an S when overriding a method that expected a T.

Your suggestion to accept that an overriding a method uses arguments that are subtypes of those requested by the overridden method is much more complicated since it leads to unsoundness in the type system.

By one hand, by the same subtyping rules mentioned above, most likely it already works for what you want to do. For instance

interface Hunter {
   public void hunt(Animal animal);
}

Nothing prevents implementations of this class from receiving any kind of animal, as such it already satisfies the criteria in your question.

But let’s suppose we could override this method as you suggested:

class MammutHunter implements Hunter {
  @Override
  public void hunt(Mammut animal) {
  }
}

Here’s the funny part, now you could do this:

AnimalHunter hunter = new MammutHunter();
hunter.hunt(new Bear()); //Uh oh

As per the public interface of AnimalHunter you should be able to hunt any animal, but as per your implementation of MammutHunter you only accept Mammut objects. Therefore the overriden method does not satisfy the public interface. We just broke the soundness of the type system here.

You can implement what you want by using generics.

interface AnimalHunter<T extends Animal> {
   void hunt(T animal);
}

Then you could define your MammutHunter

class MammutHunter implements AnimalHunter<Mammut> {
   void hunt(Mammut m){
   }
}

And using generic covariance and contravariance you can relax the rules in your favor when necessary. For instance we could make sure that a mammal hunter can only hunt felines in a given context:

AnimalHunter<? super Feline> hunter = new MammalHunter();
hunter.hunt(new Lion());
hunter.hunt(new Puma());

Supposing MammalHunter implements AnimalHunter<Mammal>.

In that case this would not be accepted:

hunter.hunt(new Mammut()):

Even when mammuts are mammals it would not be accepted due to the restrictions on the contravariant type we are using here. So, you can still excercice some controll over the types to do things like the ones you mentioned.

The problem is not what you do in the overriding method with the object given as argument. The problem is what is the type of arguments the code using your method is allowed to feed to your method.

An overriding method must fulfill the contract of the overridden method. If the overridden method accepts arguments of some class and you override it with a method that accepts only a subclass, it doesn’t fulfill the contract. That is why it is not valid.

Overriding a method with a more specific type of argument is called overloading. It defines a method with the same name but with a different or more specific type of argument. An overloaded method is available besides the original method. Which method is called depends on the type known at compile time. To overload a method you have to drop the @Override annotation.