Log record mutations are visible in next registered processors

CHANGELOG.md

@@ -25,6 +25,8 @@ release.
 
 - Add the in-development `Enabled` API to the `Logger`.
   ([#4020](https://github.com/open-telemetry/opentelemetry-specification/pull/4020))
+- Log record mutations do not have to be visible in next registered processors. Allow chaining processors and having the log record modifications local.
+  ([#4067](https://github.com/open-telemetry/opentelemetry-specification/pull/4067))
 
 ### Events
 

specification/logs/sdk.md

@@ -317,9 +317,22 @@ therefore it SHOULD NOT block or throw exceptions.
 
 **Returns:** `Void`
 
-A `LogRecordProcessor` may freely modify `logRecord` for the duration of
-the `OnEmit` call. If `logRecord` is needed after `OnEmit` returns (i.e. for
-asynchronous processing) only reads are permitted.
+It is implementation specific whether and how the `logRecord` passed by the SDK
+is shared between the processors. Log record mutations do not have to be visible
+in next registered processors.
+
+If the `logRecord` is shared, then a `LogRecordProcessor` may freely modify
+`logRecord` only for the duration of the `OnEmit` call.
+The modifications applied on shared data are visible in next
+registered processors.
+If `logRecord` is needed after `OnEmit` returns (i.e. for asynchronous
+processing) only reads are permitted.
+
+If the `logRecord` is not shared, then modifications applied on the `logRecord`
+are local.
+If the modification is needed in another processor,
+then the processor making the modification needs to call the other processor's
+`OnEmit` and pass the locally modified `logRecord`.
 
 #### ShutDown