fix: use consistent words and add clarification for semi modular extension

Author: fangting-alchemy

standard/ERCs/erc-6900.md

@@ -44,9 +44,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
   - **Validation functions** validate authorization on behalf of the account.
   - **Execution functions** execute custom logic allowed by the account.
   - **Hooks** execute custom logic and checks before and/or after an execution function or validation function.
-There are two types of hooks:
-    - **Validation hook** functions run before a validation function. These can enforce permissions on actions authorized by a validation function.
-    - **Execution hook** functions run can run before and/or after an execution function. The pre execution hook may optionally return data to be consumed by a post execution hook functions.
+    There are two types of hooks: - **Validation hook** functions run before a validation function. These can enforce permissions on actions authorized by a validation function. - **Execution hook** functions run can run before and/or after an execution function. The pre execution hook may optionally return data to be consumed by a post execution hook functions.
 - A **native function** refers to a function implemented by the modular account, as opposed to a function added by a module.
 - A **module** is a deployed smart contract that hosts any amount of the above three kinds of modular functions.
 - A module **manifest** describes the execution functions, interface ids, and hooks that should be installed on the account.
@@ -572,7 +570,7 @@ The `executeFromModuleExternal` function MUST allow modules to call external add
 
 #### Semi-modular account
 
-Account implementers may opt to design a semi-modular account, where certain features, such as default validation, are integrated into the core account. This approach should ensure compatibility with fully modular accounts, maintaining interoperability across different implementations.
+Account implementers MAY choose to design a semi-modular account, where certain features, such as default validation, are integrated into the core account. This approach SHOULD ensure compatibility with fully modular accounts, as defined in this proposal, to maintain interoperability across different implementations.
 
 ## Rationale