Q:

In some IOC contexts, could constructor of polymorphic immutable object be required in its interface? 

Generally, constructors in an interface are considered as being an anti-pattern.  Some languages even don't allow that. 
Then I don't understand how we're supposed to deal with polymorphic immutable objects in the some particular IOC contexts...
Say we have to instantiate a polymorphic object, its class implementing our interface is implemented and supplied by the client. 
 As a dumb but simple scenario let's say this object is a value object and as such should be immutable, which mean the object's state should be valid from the moment it's instantiated…
Our code:
// A user class implementing our interface...
$immutablePolymorphe = $userConfig['immutable_polymorphe_class'];

// Here we must know what to inject to its constructor...
$immutablePolymorphe = new $immutablePolymorphe($state);

// Then do something with that polymorphe...

So don't we have to constrain the constructor here, hence the interface?  Am I missing something? 

A:

In an OOP context, having a constructor in an interface makes zero sense: The concrete type – which would be needed to construct an instance of a type – isn't known to the consumers of an interface.  All a consumer knows is that a given object implements that interface and can be sent various messages. 
However, not all programming is object-oriented.  When using techniques such as generics or templates, we are using interfaces/typclasses/traits/concepts not to constrain objects, but to constrain types.  Requiring that a type then offers a particular constructor makes perfect sense.  In fact, some languages (such as Rust or Haskell) do not have a similar concept of a “constructor”, but only ordinary functions that happen to return an instance of that type – and allow such non-instance functions to be part of an interface. 
It is usually not possible to write an interface that requires an object to be immutable.  While an interface might not offer any mutators, it could provide additional methods that do change its state.  I'm therefore not sure whether your IOC example could be realized in a typical language. 

Regarding the dependency injection example in the question, a typical solution is to not inject a class with its constructor, but to inject an arbitrary factory function that is able to construct a suitable object.  This factory function can be given lots of possible dependencies but does not have to use them, thus allowing us to abstract over the specific signature of the real constructor.  For example:
function make_A($dep_a, $dep_b) {
  return new ImplementationA($dep_a);
}
function make_B($dep_a, $dep_b) {
  return new ImplementationB($dep_a, $dep_b);
}

// in some configuration:
$DI_CONFIG['SomeInterface'] = make_A;  // or make_B

// in the DI container:
$dep_a = ...;  // resolve dependency
$dep_b = ...;
$some_instance = $DI_CONFIG['SomeInterface']($dep_a, $dep_b)

