diff --git a/content/docs/reconciliation.md b/content/docs/reconciliation.md
index 245b5c715..f76e83f10 100644
--- a/content/docs/reconciliation.md
+++ b/content/docs/reconciliation.md
@@ -138,9 +138,9 @@ In practice, finding a key is usually not hard. The element you are going to dis
 
 When that's not the case, you can add a new ID property to your model or hash some parts of the content to generate a key. The key only has to be unique among its siblings, not globally unique.
 
-As a last resort, you can pass item's index in the array as a key. This can work well if the items are never reordered, but reorders will be slow.
+As a last resort, you can pass an item's index in the array as a key. This can work well if the items are never reordered, but reorders will be slow.
 
-There can also be issues with the state of a component in a list if indexes are used as keys. The state of an item in a list (or any deep state inside of it) will stay attached to the original position of the item, even if the item has “moved” in the data source. This is particularly noticeable with inputs retaining their values in the original positions even when their parent components reorder or are prepended to.
+Reorders can also cause issues with component state when indexes are used as keys. Component instances are updated and reused based on their key. If the key is an index, moving an item changes it. As a result, component state for things like controlled inputs can get mixed up and updated in unexpected ways.
 
 [Here](codepen://reconciliation/index-used-as-key) is an example of the issues that can be caused by using indexes as keys on CodePen, and [here](codepen://reconciliation/no-index-used-as-key) is a updated version of the same example showing how not using indexes as keys will fix these reordering, sorting, and prepending issues.