diff --git a/eeps/eep-0066.md b/eeps/eep-0066.md
index e29bfe2..bcf8285 100644
--- a/eeps/eep-0066.md
+++ b/eeps/eep-0066.md
@@ -45,8 +45,8 @@ Design Decisions
 ----------------
 
 In the following text double angle quotation marks are used to
-mark source code characters in a paragraph.  For example:
-«`.`» means the dot character (full stop).
+mark source code characters to improve clarity.
+For example: the dot character (full stop): «`.`».
 
 ### Erlang Language Structure (Tokenizer and Parser)
 
@@ -76,9 +76,9 @@ much state and looks just a few fixed number of characters ahead
 in the input.
 
 For example; from the start state, if the tokenizer sees
-a «`'`» character, it switches state to scanning a quoted atom.
-While doing so it translates escape sequences such as «`\n`»
-(into ASCII 10) and when it sees a «`'`» character it produces
+a `'` character, it switches state to scanning a quoted atom.
+While doing so it translates escape sequences such as `\n`
+(into ASCII 10) and when it sees a `'` character it produces
 an atom token and goes back to the start state.
 
 ### Problems with simple prefixes
@@ -92,7 +92,7 @@ The tokenizer would have to know of all combinations of prefix characters
 and emit distinct tokens for every combination.
 
 Today, the character sequence «`b`», «`f`», «`"`» is scanned as a token
-for the atom «`bf`» followed by the string start token «`"`».
+for the atom `bf` followed by the string start token `"`.
 That combination fails in the parser so it is syntactically invalid today,
 which is what makes simple prefixes a possible language extension.
 
@@ -107,30 +107,30 @@ Furthermore, it is likely that we want the feature of choosing
 
     re(^"+.*/.*$)
 
-Among the desired delimiters are «`/`» and «`<`»+«`>`».  The currently
-valid code «`b<X`» meaning atom «`b`» less than «`X`», would instead
-have to be interpreted as prefixed string start «`b<`» with «`X`»
+Among the desired delimiters are `/` and `< >`.  The currently
+valid code «`b<X`» meaning atom `b` less than `X`, would instead
+have to be interpreted as prefixed string start `b<` with `X`
 being the first string content character.
 
-For the «`/`» character we run into similar problems with for example
+For the `/` character we run into similar problems with for example
 «`b/X`», which would be a run-time error today, but if we also would
 want capital letter prefixes, then «`B/X`» is perfectly valid today
 but would become a string start.
 
 There are more likely problems with simple string prefixes:
-«`#bf{`» is today the start of a record named «`bf`», and is
-scanned as punctuation character «`#`», atom «`bf`» and separator «`{`»,
-which the parser sorts out to be a record start.
+«`#bf{`» is today the start of a record named `bf`, and is
+scanned as punctuation character `#`, atom `bf` and separator `{`,
+which the parser figures out to be a record start.
 
 With simple prefix characters the tokenizer would have to be rewritten
 to recognize «`#bf`» as a new record token, a rewrite that might cause
 unexpected changes in record handling.  For example, today, «`# bf {`»
-is also a valid record start, so to be completely compatible the tokenizer
+is also a valid record start, so to be compatible the tokenizer
 would have to allow white-space or even newlines within the new record
-token, between «`#`» and the atom characters, which would be really ugly...
+token, between `#` and the atom characters, which would be really ugly...
 
 For other reasons, namely that function call parenthesis are optional,
-Elixir has chosen to use the «`~`» character as the start of
+Elixir has chosen to use the `~` character as the start of
 a string prefix which they call a "[Sigil][1]".
 
 Having a distinct start character for this feature simplifies
@@ -139,41 +139,64 @@ tokenizing and parsing.
 ### Sigil
 
 In a general sense, a [Sigil][3], is a prefix to a variable
-that indicates its *type*, such as «`$I`» in Basic or Perl,
-where «`$`» is the sigil and «`I`» is the variable.
+that indicates its *type*, such as `$I` in Basic or Perl,
+where `$` is the sigil and `I` is the variable.
 
-Here we define a Sigil as a prefix (and a suffix) to a string literal
-that indicates how it should be *interpreted*.  The Sigil is
-a *syntactic sugar* that creates some Erlang term.
+Here we define a Sigil as a prefix (and maybe a suffix) to
+a string literal that indicates how it should be *interpreted*.
+The Sigil is a *syntactic sugar* that is transformed into
+some Erlang term, or expression.
 
 A Sigil string literal consists of:
 
-1. The [Sigil Prefix][], «`~`» followed by a name that may be empty.
+1. The [Sigil Prefix][], `~` followed by a name that may be empty.
 2. The [String Content][] within [String Delimiters][].
 3. The [Sigil Suffix][], a name character sequence that may be empty.
 
+### Sigil Transformation
+
+The sigil is transformed early by the tokenizer and the parser
+into some other term or expression.  Later steps in the
+parsing and compilation finds out if the transformation
+result is valid.
+
+#### Patterns and Expressions
+
+Where the transformed term is valid depends on what it was
+transformed into.  For example, if the sigil is transformed
+into some other literal term, it would be valid in a pattern.
+
+Should the sigil have become something containing
+a function call, then it is only valid in a general
+expression, not in a pattern.
+
+#### String Concatenation
+
+Adjacent strings are concatenated by the parser so for example
+«`"abc" "def"`» is concatenated to `"abcdef"`.
+
 A Sigil looks like a string with a prefix (and maybe a suffix),
-but expands to some term (or expression), so it cannot be subject
-to the string concatenation the parser does.
+but may be transformed into something other than a string,
+so it cannot be subject to string concatenation.
 
-Therefore `"abc" "def"` is `"abcdef"` but `~s"abc" "def"`
-should be illegal, and also all other sequences consisting
-of a Sigil of any type, and any other term, in any order.
+Therefore «`~s"abc" "def"`» should be illegal, and also all other
+sequences consisting of a Sigil of any type, and any other term,
+in any order.
 
 ### Sigil Prefix
 
-The Sigil Prefix starts whith the Tilde character «`~`», followed
+The Sigil Prefix starts whith the Tilde character `~`, followed
 by the Sigil Type which is a name composed of a sequence of characters
 that are allowed as the second or later characters in a variable or an atom.
-In short ISO [Latin-1][] letters, digits, «`_`» and «`@`».
+In short ISO [Latin-1][] letters, digits, `_` and `@`.
 The Sigil Type may be empty.
 
 The Sigil Type defines how the [Sigil][] syntactic sugar
 shall be interpreted.  The suggested Sigil Types are:
 
-* «»: the vanilla (default) [Sigil][].
+* «»: the vanilla (default (empty name)) [Sigil][].
 
-  Creates an Erlang `unicode:unicode_binary()`.
+  Creates a literal Erlang `unicode:unicode_binary()`.
   It is a string represented as a UTF-8 encoded binary,
   equivalent to applying `unicode:characters_to_binary/1`
   on the [String Content][].  The [String Delimiters][]
@@ -191,46 +214,46 @@ shall be interpreted.  The suggested Sigil Types are:
   the first and most desired missing string feature in Erlang.
   This sigil does just that.
 
-* «`b`»: `unicode:unicode_binary()`
+* `b`: `unicode:unicode_binary()`
 
-  Creates a UTF-8 encoded binary, handling escape characters
+  Creates a literal UTF-8 encoded binary, handling escape characters
   in the string content.  Other features such as string interpolation
   will require another Sigil Type or using the [Sigil Suffix][].
 
-  In Elixir this corresponds to the «`~s`» sigil, a [string][4].
+  In Elixir this corresponds to the `~s` sigil, a [string][4].
 
-* «`B`»: `unicode:unicode_binary()`, verbatim.
+* `B`: `unicode:unicode_binary()`, verbatim.
 
-  Creates a UTF-8 encoded binary, with verbatim string content
-  in that only the [end delimiter][] character can be escaped
-  with a «`\`» character.
+  Creates a literal UTF-8 encoded binary, with verbatim string content.
+  The content ends when the end delimiter is found.
+  There is no way to escape the end delimiter.
 
-  In Elixir this corresponds to the «`~S`» sigil, a [string][4].
+  In Elixir this corresponds to the `~S` sigil, a [string][4].
 
-* «`s`»: `string()`.
+* `s`: `string()`.
 
-  Creates a Unicode codepoint list, handling escape characters
+  Creates a literal Unicode codepoint list, handling escape characters
   in the string content.  Other features such as string interpolation
   will require another Sigil Type or using the [Sigil Suffix][].
 
-  In Elixir this corresponds to the «`~c`» sigil, a [charlist][5].
+  In Elixir this corresponds to the `~c` sigil, a [charlist][5].
 
-* «`S`»: `string()`, verbatim.
+* `S`: `string()`, verbatim.
 
-  Creates a Unicode codepoint list, with verbatim string content
-  in that only the [end delimiter][] character can be escaped
-  with a «`\`» character.
+  Creates a literal Unicode codepoint list, with verbatim string content.
+  The content ends when the end delimiter is found.
+  There is no way to escape the end delimiter.
 
-  In Elixir this corresponds to the «`~C`» sigil, a [charlist][5].
+  In Elixir this corresponds to the `~C` sigil, a [charlist][5].
 
-* «`r`»: regular expression.
+* `r`: regular expression.
 
-  This EEP proposes to not implement regulare expressions yet.
+  This EEP proposes to not implement regular expressions yet.
   It is still unclear how integration with the `re` module
   should be done, and if it is worth the effort compared
-  to just using the «`S`» or the «`B`» Sigil Type.
+  to just using the `S` or the `B` Sigil Type.
 
-  The best idea so far was that this sigil creates a term
+  The best idea so far was that this sigil creates a literal term
   `{re,RE::unicode:charlist(),Flags::[unicode:latin1_char()]}`
   that is an uncompiled regular expression with compile flags,
   suitable for (yet to be implemented) functions in the `re` module.
@@ -240,18 +263,18 @@ shall be interpreted.  The suggested Sigil Types are:
   See the [Regular Expressions][] section about the reasoning
   behind this proposed term type.
 
-  Within the [String Content][], character escape sequences are handled
-  according to the regular expression rules, and in addition to them
-  the [end delimiter][] character can be escaped with a «`\`» character.
-  Between triple-quote delimiters according to [EEP 64][]
-  there is no end delimiter character to escape.
+  First the [end delimiter][] is found and within the [String Content][],
+  character escape sequences are handled according to
+  the regular expression rules.
 
   The main advantage of a regular expression [Sigil][] is to avoid
-  the additional escaping of «`\`» that regular erlang strings require.
+  the additional escaping of `\` that regular erlang strings require.
+
+  Looking for name\\number in quotes such as: `"foo\17"`
 
   Today: `re:run(Subject, "^\\s*\"[a-z]+\\\\\\d+\"", [caseless,unicode])`
 
-  Sigil: `re:run(Subject, ~r'^\s*"[a-z]+\\\d+"'iu)`
+  Sigil: `re:run(Subject, ~r/^\s*"[a-z]+\\\d+"/iu)`
 
   Other advantages are possible tools and library integration features
   such as making the `re` module recognize this tuple format,
@@ -266,9 +289,9 @@ since they are often a source for hard to find problems.
 
 These proposed Sigil Types are named according to the corresponding
 Erlang types.  The Sigil Types in [Elixir][1] are named according to
-Elixir types.  So, for example, a «`~s`» Sigil Prefix in Erlang
+Elixir types.  So, for example, a `~s` Sigil Prefix in Erlang
 creates an Erlang `string()`, which is a list of Unicode codepoints,
-but in Elixir the «`~s`» Sigil Prefix creates an Elixir [String][4]
+but in Elixir the `~s` Sigil Prefix creates an Elixir [String][4]
 which is a UTF-8 encoded binary.
 
 Consistency within the language is supposedly more important
@@ -281,20 +304,14 @@ Immediately following the [Sigil Prefix][] is the string start delimiter.
 A specific start delimiter character has a corresponding
 end delimiter character.
 
-Elixir has got the following start-end delimiter character pairs:
-«`()`», «`[]`», «`{}`», and «`<>`», and the following characters
-are start delimiters that have themselves as end delimiters:
-«`/`», «`|`», «`'`», and «`"`».
+The allowed start-end delimiter character pairs are:
+`() [] {} <>`.
 
-This EEP proposes to so far only implement the regular string
-start and end delimiter «`"`» as single character demiliter.
-It is the established string delimiter in Erlang and will
-create no confusion.  The other can be added later
-and by not allowing them yet it will still be possible for them
-to have different semantics, if we find some good use for that.
+The following characters are start delimiters that have themselves
+as end delimiters: `` / | ' " ` # ``.
 
 Triple-quote delimiters are also allowed, that is; a sequence of
-3 or more double quote «`"`» characters as described in [EEP 64][].
+3 or more double quote `"` characters as described in [EEP 64][].
 
 For a given [Sigil Type][] except the [Vanilla Sigil][],
 which String Delimiters that are used does not affect how
@@ -304,6 +321,31 @@ For a triple-quoted string, though, conceptually the end delimiter
 doesn't occur in the string's content, so interpreting the string content
 does not interfere with finding the end delimiter.
 
+The proposed set of delimiters is the same as in [Elixir][1],
+plus `` ` `` and `#`.  They are the characters in [ASCII][]
+that are normally used for bracketing or text quoting,
+and those that feel like full height vertikal lines,
+except: `\` is too often used for character escaping,
+plus `#` which is too useful to *not* include since
+in many contexts (shell scripts, Perl regular expressions)
+it is a comment character that is easy to avoid
+in the [String Content][].
+
+Even though [Latin-1][] is the character set that Erlang
+is defined in, it is still [ASCII][] that is the common denominator
+for programming languages.  Only western Europeean keyboards
+and code pages that have the possibility to produce [Latin-1][]
+characters above 127.
+
+[Latin-1][] characters above 127 are allowed in variable names
+and unquoted atoms, but the programmer that uses such should
+be aware that the code will not read correctly for
+non-[Latin-1][] users.  On the other hand it would be bad to lure
+a programmer into using e.g a quote character that happens to exist
+on a [Latin-1][] keyboard but will be something completely different
+for other programmers.  Therefore characters like `« »`
+should *not* be used for a general syntactical element.
+
 ### String Content
 
 Between the start and end [String Delimiters][], all characters
@@ -314,7 +356,7 @@ of indentation and leading and trailing newline is done as usual
 as described in [EEP 64][].
 
 In a string with single character [String Delimiters][],
-normal Erlang escape sequences prefixed with «`\`» are honoured,
+normal Erlang escape sequences prefixed with `\` are honoured,
 as usual for regular Erlang strings and quoted atoms
 
 A specific [Sigil Type][] can have it's own character escaping rules,
@@ -330,10 +372,10 @@ of name characters.
 
 The Sigil Suffix may indicate how to interpret the String Content,
 for a specific [Sigil Type][].
-For example; for the «`~r`» [Sigil Prefix][] (regular expression),
+For example; for the `~R` [Sigil Prefix][] (regular expression),
 the Sigil Suffix is interpreted as short form compile options
 such as «`i`» that makes the regular expression character
-case insensitive.
+case insensitive.  For example «`~R/^from: /i`».
 
 Things that may have to be performed by the tokenizer, such as
 how to handle escape character rules, should not be affected
@@ -346,7 +388,7 @@ or the parser.
 
 ### Regular Expressions
 
-A regular expression sigil «`~r"expression"flags`» should
+A regular expression sigil «`~R"expression"flags`» should
 be translated to something useful for tools/libraries.
 There are at least two ways; [uncompiled regular expressions][],
 or [compiled regular expressions][].
@@ -411,41 +453,47 @@ should represent an *uncompiled* regular expression with compile flags.
 
 ### Comparison with Elixir
 
-The [Vanilla Sigil][] (empty [Sigil Type][]) is not allowed in Elixir.
+There is no [Vanilla Sigil][] (empty [Sigil Type][]) in Elixir.
 
-This EEP proposes to only implement the «`"`» [String Delimiters][],
-for starters.  Elixir has got a much wider set.
+This EEP proposes to add the following [String Delimiters][]
+to the set that Elixir has: `` # ` ``.
 
 The string and binary [Sigil Type][]s are named differently
 between the languages, to keep the names consistent within
-the language (Erlang): «`~s`» in Elixir is «`~b`» in Erlang,
-and «`~c`» in Elixir is «`~s`» in Erlang, so «`~s`» means
+the language (Erlang): `~s` in Elixir is `~b` in Erlang,
+and `~c` in Elixir is `~s` in Erlang, so `~s` means
 different things, because strings are different things.
 
 When Elixir allows escape sequences in the [String Content][]
 it also allows string interpolation.  This EEP proposes to *not*
 implement string interpolation in the suggested [Sigil Type][]s.
 
+When Elixir doesn't allow escape sequences in the [String Content][],
+it still allows escaping the end delimiter.  This EEP proposes
+that such strings should be truly verbatim whith no possibility
+to escape the end delimiter.
+
 There are small differences in which escape sequences that are implemented
 in the languages; Elixir allows escaping of newlines, and has
-an escape sequence «`\a`», that Erlang does not have.
+an escape sequence `\a`, that Erlang does not have.
 
 There are also small differences in how newlines are handled
-between «`~S`» heredocs in Elixir and triple-quoted strings in Erlang.
+between `~S` heredocs in Elixir and triple-quoted strings in Erlang.
 See [EEP 64][].
 
-Details about regular expression sigils, «`~r`», in particular
+Details about regular expression sigils, `~R`, in particular
 their [Sigil Suffix][]es remains to be decided in Erlang.
+Also, there still is a question about escaping the end delimiter or not.
 
 It has not been decided how or even *if* string interpolation
-in will be implemented in Erlang, but a [Sigil Suffix][] or
+will be implemented in Erlang, but a [Sigil Suffix][] or
 new [Sigil Type][]s would most probably be used.
 
 Reference Implementation
 ------------------------
 
-[PR-7684][] Implements the «`s`», «`S`», «`b`», «`B`»
-and the «``» (vanilla) Sigil, according to this EEP.
+[PR-7684][] Implements the `~s`, `~S`, `~b`, `~B`
+and the `~` (vanilla) Sigil, according to this EEP.
 
 The tokenizer produces a `sigil_prefix` token before the string literal,
 and a `sigil_suffix` token after.  The parser merges and transforms them
@@ -478,6 +526,9 @@ more tokenizer rewriting.
 [Latin-1]:    https://en.wikipedia.org/wiki/ISO/IEC_8859-1
               "Wikipedia: ISO-IEC 8859-1"
 
+[ASCII]:      https://en.wikipedia.org/wiki/Basic_Latin_(Unicode_block)
+              "Unicode Basic Latin"
+
 [PR-7684]:    https://github.com/erlang/otp/pull/7684
               "Sigils on String Literals"