docs: Apply suggestions from code review

README.md

@@ -39,7 +39,7 @@ These resources can be helpful to refine your issue, work out an application/dri
 ### Internals
 
 The Validation Layers are broken up as many smaller internal "Validation Objects" each tasked with own job.
-[Core Checks](./docs/core_checks.md) is what is on by default, but there are other validation such as [Synchronization Validation](./docs/synchronization.md), [GPU Assisted Validation](./docs/gpu_validation.md), and [more](./docs/README.md).
+[Core Checks](./docs/core_checks.md) is what is enabled by default, but there are other validation objects that can be additionally enabled, such as [Synchronization Validation](./docs/synchronization.md), [GPU Assisted Validation](./docs/gpu_validation.md), and [more](./docs/README.md).
 There are also a few [limitations](./docs/limitations.md) that the Validation Layers can not handle due the nature of being a Vulkan Layer.
 
 ## Version Tagging Scheme

docs/limitations.md

@@ -20,7 +20,7 @@ If an app is trying to use `VkBindImageMemoryInfo`, but is setting the `sType` a
 
 The Validation Layers (as well as any other layer or driver) uses the `sType` to know how to cast the `void* pNext`, so if it is wrong, there is no way a Vulkan Layer could know.
 
-There are VUID such as `VUID-VkBufferCreateInfo-pNext-pNext` that limit which `sType` can appear in the pNext chain, but something the 2 `sType` being mixed up both might be valid to use in that case.
+There are VUID such as `VUID-VkBufferCreateInfo-pNext-pNext` that limit which `sType` can appear in the pNext chain, but something the 2 mixed up `sType` can both be valid by chance, and there will be no validation error.
 
 ### Dereferencing Pointers