Rewordings to avoid "might" and "could"

source/basic.tex

@@ -2870,7 +2870,8 @@
 or defines a constexpr variable initialized to a TU-local value (defined below).
 \begin{note}
 An inline function template can be an exposure even though
-explicit specializations of it might be usable in other translation units.
+some
+explicit specializations of it would be usable in other translation units.
 \end{note}
 
 \pnum

source/compatibility.tex

@@ -631,11 +631,11 @@
 Improve consistency of equality with three-way comparison
 and make it easier to write the full complement of equality operations.
 \effect
-Equality and inequality expressions between two objects of different types,
-where one is convertible to the other,
-could invoke a different operator.
-Equality and inequality expressions between two objects of the same type
-could become ambiguous.
+For certain pairs of types where one is convertible to the other,
+equality or inequality expressions between an object of one type
+and an object of the other type invoke a different operator.
+Also, for certain types, equality or inequality expressions
+between two objects of that type become ambiguous.
 For example:
 \begin{codeblock}
 struct A {
@@ -921,9 +921,9 @@
 \change
 Remove \tcode{raw_storage_iterator}.
 \rationale
-The iterator encouraged use of algorithms that might throw exceptions, but did
-not return the number of elements successfully constructed that might need to
-be destroyed in order to avoid leaks.
+The iterator encouraged use of potentially-throwing algorithms, but did
+not return the number of elements successfully constructed,
+as would be necessary to destroy them.
 \effect
 A valid \CppXVII{} program that uses this iterator class may fail to compile.
 
@@ -958,8 +958,8 @@
 The traits had unreliable or awkward interfaces. The \tcode{is_literal_type}
 trait provided no way to detect which subset of constructors and member
 functions of a type were declared \keyword{constexpr}. The \tcode{result_of}
-trait had a surprising syntax that could not report the result of a regular
-function type. It has been superseded by the \tcode{invoke_result} trait.
+trait had a surprising syntax that did not directly support function types.
+It has been superseded by the \tcode{invoke_result} trait.
 \effect
 A valid \CppXVII{} program that relies on the \tcode{is_literal_type} or
 \tcode{result_of} type traits, on the \tcode{is_literal_type_v} variable template,
@@ -1019,8 +1019,6 @@
 \effect
 A valid \CppXIV{} expression utilizing the increment operator on
 a \tcode{bool} lvalue is ill-formed in this revision of \Cpp{}.
-Note that this might occur when the lvalue has a type given by a template
-parameter.
 
 \diffref{expr.new,expr.delete}
 \change
@@ -1694,7 +1692,7 @@
 \rationale
 Overly constrained, simplify overload resolution rules.
 \effect
-A valid \CppIII{} program could get a different result than in this
+A valid \CppIII{} program can get a different result in this
 revision of \Cpp{}.
 
 \rSec2[diff.cpp03.library]{\ref{library}: library introduction}
@@ -2354,8 +2352,8 @@
 block.
 Allowing jump past initializers would require
 complicated runtime determination of allocation.
-Furthermore, any use of the uninitialized object could be a
-disaster.
+Furthermore, many operations on such an uninitialized object
+have undefined behavior.
 With this simple compile-time rule, \Cpp{} assures that
 if an initialized variable is in scope, then it has assuredly been
 initialized.
@@ -2411,8 +2409,8 @@
 with a type.
 In \Cpp{}, class members can be declared with the \keyword{static} storage
 class specifier.
-Allowing storage class specifiers on type
-declarations could render the code confusing for users.
+Storage class specifiers on type
+declarations can render the code confusing for users.
 \effect
 Deletion of semantically well-defined feature.
 \difficulty
@@ -2786,8 +2784,8 @@
 \indextext{bit-field!implementation-defined sign of}%
 Bit-fields of type plain \keyword{int} are signed.
 \rationale
-Leaving the choice of signedness to implementations could lead to
-inconsistent definitions of template specializations. For consistency,
+The signedness needs to be consistent among template specializations.
+For consistency,
 the implementation freedom was eliminated for non-dependent types,
 too.
 \effect

source/exceptions.tex

@@ -799,9 +799,7 @@
 \end{codeblock}
 The call to
 \tcode{f}
-is well-formed even though, when called,
-\tcode{f}
-might throw an exception.
+is well-formed even though it is not known whether \tcode{f} throws any exception.
 \end{example}
 
 \pnum