docs: avoid using support for features; don't mention coming soon

docs/src/modules/ROOT/pages/index.adoc

@@ -34,7 +34,7 @@ Developers can access a local console that replicates runtime observability, tra
 
 == DevOps Operations
 Operators can configure application elasticity without deep architectural knowledge. Akka automates instance management to meet traffic needs while preserving performance SLAs. Services can be replicated across multiple regions, spanning different geographies and environments.
-Stateful services can be read-replicated or write-replicated (Q1 2025) with conflict resolution options. Services can migrate between locations without downtime and can be restarted from specific points in time.
+Stateful services can be read-replicated or write-replicated with conflict resolution options. Services can migrate between locations without downtime and can be restarted from specific points in time.
 Developers have access to a component library for creating various application types, including transactional, durable, Artificial Intelligence (AI) Retrieval-Augmented Generation (RAG), analytics, edge, event-sourced, and streaming applications.
 
 == Key Components

docs/src/modules/concepts/pages/development-process.adoc

@@ -53,7 +53,7 @@ Services can interact asynchronously with other services and with external syste
 
 === Workflows
 
-Akka Workflows are high-level descriptions to easily align business requirements with their implementation in code. Orchestration across multiple services with support for failure scenarios and compensating actions is simple with xref:java:workflows.adoc[Workflows].
+Akka Workflows are high-level descriptions to easily align business requirements with their implementation in code. Orchestration across multiple services including failure scenarios and compensating actions is simple with xref:java:workflows.adoc[Workflows].
 
 === Views
 

docs/src/modules/concepts/pages/multi-region.adoc

@@ -1,21 +1,24 @@
-= Multi-region support
+= Multi-region operations
 
 include::ROOT:partial$include.adoc[]
 
-Akka's opinionated approach to domain modelling allow for applications to run in multiple regions without modification. An Akka application written as a single region application can be turned into a multi-region application with nothing more than a change in deployment configuration.
+Akka applications run in multiple regions with their data transparently and continuously replicated even across multiple cloud providers.
+Akka applications do not require code modifications to run within multiple regions. Operators define controls to determine which regions
+an application will operate within and whether that application's data is pinned to one region or replicated across many.
 
-The multi-region use cases that Akka's multi-region support encompasses include:
+Akka ensures regardless of which region receives a request, the request can be serviced. Multiple replication strategies can be configured, with each offering varying features for different use cases.
 
+Multi-region operations are ideal for:
+
+* Applications that require 99.9999% availability
 * Geographic failover
 * Geo-homing of data for low latency access
 * Low latency global reads
-* Low latency global writes (coming soon)
-
-Akka ensures that no matter which region receives a request, the request can be serviced. Multiple replication strategies can be configured, with each offering varying features for different use cases.
+* Low latency global writes
 
 == Examples
 
-The two main replication strategies that Akka offers are replicated reads, and replicated writes (coming soon).
+The two main replication strategies that Akka offers are replicated reads, and replicated writes.
 
 === Replicated reads
 
@@ -47,6 +50,6 @@ image:geo-d.svg[Geo data replication, width=600]
 
 When Bob travels to the USA, read requests that Bob makes on his data are handled locally, while write requests are forwarded to the UK. Meanwhile, write requests made by Alice on her data is all handled locally, with writes being replicated to the UK.
 
-=== Replicated writes (coming soon)
+=== Replicated writes
 
 The replicated write replication strategy allows every region to be capable of handling writes for all entities. This is done through the use of CRDTs, which can be modified concurrently in different regions, and their changes safely merged without conflict.

docs/src/modules/concepts/pages/state-model.adoc

@@ -6,7 +6,7 @@ Entities are used to store the data defined in the xref:concepts:architecture-mo
 
 Entities have operations that can change their state. These operations are triggered asynchronously and implemented via methods that return xref:concepts:declarative-effects.adoc[`Effect`]. Operations allow entities to be dynamic and reflect the most up-to-date information and this all gets wired together for you.
 
-Akka supports two state models: _Event Sourced Entity_ and _Key Value Entity_. Event Sourced Entities build their state incrementally by storing each update as an event, while Key Value Entities store their entire state as a single entry in a Key/Value store. To replicate state across clusters and regions, Akka uses specific conflict resolution strategies for each state model.
+Akka offers two state models: _Event Sourced Entity_ and _Key Value Entity_. Event Sourced Entities build their state incrementally by storing each update as an event, while Key Value Entities store their entire state as a single entry in a Key/Value store. To replicate state across clusters and regions, Akka uses specific conflict resolution strategies for each state model.
 
 NOTE: Although Key Value Entities are planned to support a Last Writer Wins (LWW) mechanism, this feature is not yet available.
 

docs/src/modules/java/pages/access-control.adoc

@@ -13,7 +13,7 @@ For a conceptual introduction, see xref:security:acls.adoc[] in the **Security**
 
 A principal in Akka is an abstract concept that represents anything that can make or be the source of a request.
 Principals that are currently supported by Akka include other services, and the internet. Services are identified
-by the service name chosen when deployed. Akka uses mTLS support to associate requests with one or more principals.
+by the service name chosen when deployed. Akka uses mutual TLS (mTLS) to associate requests with one or more principals.
 
 Note that requests that have the internet principal are requests that Akka has identified as coming through the Akka
 ingress route. This is identified by mTLS, however it does not imply that mTLS has been

docs/src/modules/java/pages/auth-with-jwts.adoc

@@ -101,7 +101,7 @@ include::example$endpoint-jwt/src/main/java/hellojwt/api/HelloJwtEndpoint.java[t
 <2> Note that while calling `Optional#get()` is generally a bad practice, here we know the claims must be present given the `@JWT` configuration.
 
 
-== Running locally with JWT support
+== Running locally with JWTs enabled
 
 When running locally, by default, a dev key with id `dev` is configured for use. This key uses the JWT `none` signing algorithm, which means the signature of the received JWT tokens is not validated. Therefore, when calling an endpoint with a bearer token, only the presence and values of the claims are validated.