A few more removals of use of typed, where makes sense, #24717 (#27819)

Remaining ones I think are still needed still

akka-docs/src/main/paradox/extending-akka.md

@@ -83,7 +83,7 @@ Java
 ## Applicability
 
 The sky is the limit!
-By the way, did you know that Akka's `Typed Actors`, `Serialization` and other features are implemented as Akka Extensions?
+By the way, did you know that Akka `Cluster`, `Serialization` and other features are implemented as Akka Extensions?
 
 <a id="extending-akka-settings"></a>
 ### Application specific settings

akka-docs/src/main/paradox/project/migration-guide-2.5.x-2.6.x.md

@@ -511,7 +511,7 @@ Akka Typed APIs are still marked as [may change](../common/may-change.md) and a
 made before finalizing the APIs. Compared to Akka 2.5.x the source incompatible changes are:
 
 * `Behaviors.intercept` now takes a factory function for the interceptor.
-* `ActorSystem.scheduler` previously gave access to the classic `akka.actor.Scheduler` but now returns a typed specific `akka.actor.typed.Scheduler`.
+* `ActorSystem.scheduler` previously gave access to the classic `akka.actor.Scheduler` but now returns a specific `akka.actor.typed.Scheduler`.
   Additionally `schedule` method has been replaced by `scheduleWithFixedDelay` and `scheduleAtFixedRate`. Actors that needs to schedule tasks should
   prefer `Behaviors.withTimers`.
 * `TimerScheduler.startPeriodicTimer`, replaced by `startTimerWithFixedDelay` or `startTimerAtFixedRate`

akka-docs/src/main/paradox/typed/actors.md

@@ -149,7 +149,7 @@ The next example is more realistic and demonstrates some important patterns:
 * Using @scala[a sealed trait and case class/objects]@java[an interface and classes implementing that interface] to represent multiple messages an actor can receive
 * Handle sessions by using child actors
 * Handling state by changing behavior
-* Using multiple typed actors to represent different parts of a protocol in a type safe way
+* Using multiple actors to represent different parts of a protocol in a type safe way
 
 ### Functional Style
 

akka-docs/src/main/paradox/typed/interaction-patterns.md

@@ -16,7 +16,7 @@ To use Akka Actor Typed, you must add the following dependency in your project:
 
 ## Introduction
 
-Interacting with an Actor in Akka Typed is done through an @scala[`ActorRef[T]`]@java[`ActorRef<T>`] where `T` is the type of messages the actor accepts, also known as the "protocol". This ensures that only the right kind of messages can be sent to an actor and also that no one else but the Actor itself can access the Actor instance internals.
+Interacting with an Actor in Akka is done through an @scala[`ActorRef[T]`]@java[`ActorRef<T>`] where `T` is the type of messages the actor accepts, also known as the "protocol". This ensures that only the right kind of messages can be sent to an actor and also that no one else but the Actor itself can access the Actor instance internals.
 
 Message exchange with Actors follow a few common patterns, let's go through each one of them. 
 
@@ -59,7 +59,7 @@ Java
 
 Many interactions between actors requires one or more response message being sent back from the receiving actor. A response message can be a result of a query, some form of acknowledgment that the message was received and processed or events that the request subscribed to. 
 
-In Akka Typed the recipient of responses has to be encoded as a field in the message itself, which the recipient can then use to send (tell) a response back.
+In Akka the recipient of responses has to be encoded as a field in the message itself, which the recipient can then use to send (tell) a response back.
 
 With the following protocol:
 

akka-docs/src/main/paradox/typed/persistence.md

@@ -82,7 +82,7 @@ Java
 :  @@snip [BasicPersistentBehaviorTest.java](/akka-persistence-typed/src/test/java/jdocs/akka/persistence/typed/BasicPersistentBehaviorTest.java) { #structure }
 
 The first important thing to notice is the `Behavior` of a persistent actor is typed to the type of the `Command`
-because this is the type of message a persistent actor should receive. In Akka Typed this is now enforced by the type system.
+because this is the type of message a persistent actor should receive. In Akka this is now enforced by the type system.
 
 The components that make up a EventSourcedBehavior are:
 
@@ -221,7 +221,7 @@ where resilience is important so that if a node crashes the persistent actors ar
 resume operations @ref:[Cluster Sharding](cluster-sharding.md) is an excellent fit to spread persistent actors over a
 cluster and address them by id.
 
-The `EventSourcedBehavior` can then be run as with any plain typed actor as described in @ref:[actors documentation](actors.md),
+The `EventSourcedBehavior` can then be run as with any plain actor as described in @ref:[actors documentation](actors.md),
 but since Akka Persistence is based on the single-writer principle the persistent actors are typically used together
 with Cluster Sharding. For a particular `persistenceId` only one persistent actor instance should be active at one time.
 If multiple instances were to persist events at the same time, the events would be interleaved and might not be
@@ -243,14 +243,14 @@ Java
 
 ## Changing Behavior
 
-After processing a message, plain typed actors are able to return the `Behavior` that is used
+After processing a message, actors are able to return the `Behavior` that is used
 for next message.
 
-As you can see in the above examples this is not supported by typed persistent actors. Instead, the state is
+As you can see in the above examples this is not supported by persistent actors. Instead, the state is
 returned by `eventHandler`. The reason a new behavior can't be returned is that behavior is part of the actor's
 state and must also carefully be reconstructed during recovery. If it would have been supported it would mean
 that the behavior must be restored when replaying events and also encoded in the state anyway when snapshots are used.
-That would be very prone to mistakes and thus not allowed in Typed Persistence.
+That would be very prone to mistakes and thus not allowed in Akka Persistence.
 
 For basic actors you can use the same set of command handlers independent of what state the entity is in,
 as shown in above example. For more complex actors it's useful to be able to change the behavior in the sense
@@ -491,7 +491,7 @@ akka.persistence.journal.leveldb.replay-filter {
 
 ## Tagging
 
-Persistence typed allows you to use event tags without using @ref[`EventAdapter`](../persistence.md#event-adapters):
+Persistence allows you to use event tags without using @ref[`EventAdapter`](../persistence.md#event-adapters):
 
 Scala
 :  @@snip [BasicPersistentActorCompileOnly.scala](/akka-persistence-typed/src/test/scala/docs/akka/persistence/typed/BasicPersistentBehaviorCompileOnly.scala) { #tagging }

akka-docs/src/main/paradox/typed/style-guide.md

@@ -1,6 +1,7 @@
 # Style guide
 
-This is a style guide with recommendations of idioms and pattern for writing Akka Typed actors.
+This is a style guide with recommendations of idioms and pattern for writing Akka actors.
+Note that this guide does not cover the classic actor API.
 
 As with all style guides, treat this as a list of rules to be broken. There are certainly times
 when alternative styles should be preferred over the ones given here.