Clarify language and add notes what types of allocation patterns are acceptable.

Design.md

@@ -49,18 +49,19 @@ Hence, invalid Unicode will be ignored when practical, and if not practical the
 
 If the user chooses, a separate adapter can be used to detect invalid Unicode and handle it as desired.
 
-### No Memory Allocation
+### Avoid Memory Allocation
 
 Enormous troubles and inefficiencies stem from general purpose library code allocating memory as the library sees fit. This makes the library code far less usable. Memory allocation strategies should be decided upon by the user of the library, not the library.
 
 The easiest way to achieve this is to design the library to not use memory allocation at all. For example, std.path assembles paths from parts without doing allocations - it returns Voldemort ranges that the user can then use to emit the result into a buffer of the user's choosing.
 
-Library routines may allocate memory internally, but not in a way that affects the user.
+In cases where allocation is necessary, Library routines may allocate memory internally, in such a way that it does not effect the user. Additionally, allocation patterns that use internal allocations, such as Dependency Injection, may be used to allocate. Note that this may require compiler support to fully implement.
 
-### No Exceptions
+### Avoid Exceptions
 
 Exceptions are inefficient and use the GC. Of course, they cannot be used in `nothrow` code. Examine each use of an Exception to see if it can be designed out of existence, like the Replacement Character method above. Design the return value such that an error is not necessary - for example, a string search function can return an empty string if not found rather than throw an Exception.
-Investigate the use of Option types for error returns.
+
+Investigate the use of "Option" or "Sum" types for error returns.
 
 ### Header Only