diff --git a/docs/runtime/01_runtime.md b/docs/runtime/01_runtime.md
index e97669e59ee9b50a8a06177f3bc6191badbd370b..86d0c3461c4361c4cdbfe41703fba45253ccd5ce 100644
--- a/docs/runtime/01_runtime.md
+++ b/docs/runtime/01_runtime.md
@@ -264,4 +264,10 @@ A port is identified by a `(component ID, port ID)` pair, and channel is a pair
 
 This is the trick we will apply in the consensus algorithm. If a channel did not see any messages passing through it, then the components that own those ports will not have to reach consensus because they will not be part of the same synchronous region. However if a message did go through the channel then the components join the same synchronous region, and they'll have to form some sort of consensus on what interaction took place on that channel.
 
-And so the `put`ting component will only submit its own `(component ID, port ID, metadata_for_sync_round)` triplet. The `get`ting port will submit information containing `(self component ID, self port ID, peer component ID, peer port ID, metadata_for_sync_round)`. The consensus algorithm can now figure out which two ports belong to the same channel.
\ No newline at end of file
+And so the `put`ting component will only submit its own `(component ID, port ID, metadata_for_sync_round)` triplet. The `get`ting port will submit information containing `(self component ID, self port ID, peer component ID, peer port ID, metadata_for_sync_round)`. The consensus algorithm can now figure out which two ports belong to the same channel.
+
+## Component Nomenclature
+
+Earlier versions of the Reowolf runtime featured the distinction between primitive and composite components. This was put into the language from a design perspective. Primitive components could do nitty-gritty protocol execution: perform `put`/`get` operations, and entering into sync blocks. Conversely, composite components were tasked with setting up a network of interconnected components: creating channels and handing off the appropriate ports to the instantiated components.
+
+Once the runtime was capable of sending ports over channels, it became apparent that this distinction no longer made sense. Because if only primitive components can send/receive ports, and cannot create new components, then the programmer is limited to using those received ports directly in the primitive's code! And so the split between primitive and composite components was removed: only the concept of a "component" is left.
\ No newline at end of file
diff --git a/docs/runtime/04_known_issues.md b/docs/runtime/04_known_issues.md
index 4389a6bd4f015a6579d0778c04bda549741cfcb1..25f0a616e6c4ee507db8b6ecb75c2c14f12302b1 100644
--- a/docs/runtime/04_known_issues.md
+++ b/docs/runtime/04_known_issues.md
@@ -30,6 +30,8 @@ The current implementation of Reowolf has the following known issues:
 
 - The TCP listener component should probably do a `shutdown` before a `close` on the socket handle. It should also set the `SO_REUSEADDR` option.
 
+- The TCP listener and TCP sender components have not been tested extensively in a multi-threaded setup.
+
 - The way in which putting ports are ordered to block if the corresponding getter port's main inbox is full is rather silly. This led to the introduction of the "backup inbox" as it is found in the runtime's code. There is a design decision to make here, but the current implementation is a bit silly. There are two options: (a) have an atomic boolean indicating if the message slot for an inbox is full, or (b) do away with the "main inbox" alltogether, and have an unbounded message queue.
 
 - For practical use in components whose code supports an arbitrary number of peers (i.e. their code contains an array of ports that is used for communication and changes in size during the component's lifetime), the `select` statement somehow needs to support waiting on any one of those ports.