What happens depends on what you mean by "killed" and what the supervisor strategy for MyActor2 is.
If the reference to MyActor2 is stopped via the stop method, such as context.stop(myActor2), then:
Processing of the current message, if any, will continue before the actor is stopped, but additional messages in the mailbox will not be processed. By default these messages are sent to the deadLetters of the ActorSystem, but that depends on the mailbox implementation.
If the reference to MyActor2 is stopped with a PoisonPill message, then:
...the akka.actor.PoisonPill message...will stop the actor when the message is processed. PoisonPill is enqueued as ordinary messages and will be handled after messages that were already queued in the mailbox.
If the reference to MyActor2 is stopped with a Kill message, then:
Unlike PoisonPill this will cause the actor to throw a[n] ActorKilledException, triggering a failure. The actor will suspend operation and its supervisor will be asked how to handle the failure, which may mean resuming the actor, restarting it or terminating it completely.
If you stop myActor2 with context.stop or PoisonPill, then messages that are sent to that actor after it has stopped will go to dead letters. If you send myActor2 a Kill message, then whatever supervisor strategy you have defined for handling an ActorKilledException will kick in. The default supervisor strategy for handling an ActorKilledException is to stop the actor, which, as mentioned, will cause all messages sent after the actor has stopped to enter the dead letter mailbox.
You can override this default behavior by changing the supervisor strategy to restart the actor in the event of an ActorKilledException. Restarts preserve the ActorRef and are transparent to entities that have a reference to the actor: messages sent to the actor while it is restarting and afterwards will be processed normally. You could also resume the actor, which basically ignores the exception.