diff --git a/.CI/index.py b/.CI/index.py
index eda6d1a1d..7e2b81dd1 100644
--- a/.CI/index.py
+++ b/.CI/index.py
@@ -55,7 +55,7 @@
 
   <script>
     var data = {
-      "versions": ["3.6-dev", "3.5", "3.4"]
+      "versions": ["3.7-dev", "3.6", "3.5", "3.4"]
     };
 
     var buildSelect = function(select, data){
@@ -85,7 +85,7 @@
 
     var buildLink = function(version){
       var link = '';
-      if(version == '3.6-dev'){
+      if(version == '3.7-dev'){
         link = 'https://specification.modelica.org/master/MLS.html';
       }else{
         link = 'https://specification.modelica.org/maint/' + version + '/MLS.html';
@@ -94,7 +94,7 @@
     }
 
     var updateSearch = function(version){
-      if(version == '3.6-dev'){
+      if(version == '3.7-dev'){
         search.algoliaOptions.facetFilters = [
           "version:master",
           "tags:specification",
@@ -129,7 +129,7 @@
           advancedSyntax: true,
           typoTolerance: false,
           hitsPerPage: 16,
-          facetFilters: ["version:3.5", "tags:specification"]
+          facetFilters: ["version:3.6", "tags:specification"]
         }
       });
     });
diff --git a/MLS.tex b/MLS.tex
index 40fc45559..5dc914af6 100644
--- a/MLS.tex
+++ b/MLS.tex
@@ -1,11 +1,17 @@
 \documentclass[10pt,a4paper]{report}
-\usepackage{cmap}
 \NeedsTeXFormat{LaTeX2e}
+\usepackage{ifpdf}
+\ifpdf
+% While the cmap.sty README says that the package should be included "at the beginning of your preamble",
+% we need to at least load it after ifpdf due to incompatibility with LaTeXML, see:
+% - https://github.com/brucemiller/LaTeXML/issues/2035
+\usepackage{cmap}
+\fi
 \usepackage[utf8]{inputenc}
 
 % Define title for use by LaTeXML.
 % An extended title is defined separately in the 'titlepage'.
-\newcommand{\mlsversion}{3.6-dev}
+\newcommand{\mlsversion}{3.7-dev}
 \newcommand{\mlsdate}{\today}
 \title{Modelica\textsuperscript{\textregistered} Language Specification version~\mlsversion}
 
diff --git a/Makefile b/Makefile
index 004c7d179..ef10408a7 100644
--- a/Makefile
+++ b/Makefile
@@ -8,11 +8,11 @@ all: MLS.pdf MLS.html
 
 .PHONY: clean-pdf
 clean-pdf:
-	-rm *.aux MLS.log MLS.toc MLS.pdf
+	-rm MLS.pdf MLS.log *.out *.aux chapters/*.aux *.toc *.fls *.bbl *.bcf *.blg *.run.xml *.idx *.ilg *.ind
 
 .PHONY: clean-html
 clean-html:
-	-rm MLS.xml LaTeXML.cache *.html *.css *.js
+	-rm MLS.xml LaTeXML.cache MLS.fdb_latexmk *.html *.css *.js
 
 .PHONY: clean
 clean: clean-pdf clean-html
diff --git a/README.md b/README.md
index 5e52e6256..3038b8138 100644
--- a/README.md
+++ b/README.md
@@ -13,7 +13,8 @@ It provides object-oriented constructs that facilitate reuse of models, and can
 
 Version | Link                                                              | Published |
 ------- | ----------------------------------------------------------------- | --------|
-3.6-dev | [Master branch](https://github.com/modelica/ModelicaSpecification/tree/master) [HTML](https://specification.modelica.org/master/) [PDF](https://specification.modelica.org/master/MLS.pdf)| not yet |
+3.7-dev | [Master branch](https://github.com/modelica/ModelicaSpecification/tree/master) [HTML](https://specification.modelica.org/master/) [PDF](https://specification.modelica.org/master/MLS.pdf)| not yet |
+3.6 | [3.6 branch](https://github.com/modelica/ModelicaSpecification/tree/maint/3.6) [HTML](https://specification.modelica.org/maint/3.6/MLS.html) [PDF](https://specification.modelica.org/maint/3.6/MLS.pdf)| 2023 |
 3.5 | [3.5 branch](https://github.com/modelica/ModelicaSpecification/tree/maint/3.5) [HTML](https://specification.modelica.org/maint/3.5/MLS.html) [PDF](https://specification.modelica.org/maint/3.5/MLS.pdf)| 2021 |
 3.4     | [3.4 branch](https://github.com/modelica/ModelicaSpecification/tree/maint/3.4) [HTML](https://specification.modelica.org/maint/3.4/MLS.html) [PDF](https://modelica.org/documents/ModelicaSpec34.pdf)          | 2017    |
 3.3rev1 | [PDF](https://modelica.org/documents/ModelicaSpec33Revision1.pdf) | 2014    |
diff --git a/RationaleMCP/0035/POT_Header.png b/RationaleMCP/0035/POT_Header.png
new file mode 100644
index 000000000..36365b907
Binary files /dev/null and b/RationaleMCP/0035/POT_Header.png differ
diff --git a/RationaleMCP/0035/Readme.md b/RationaleMCP/0035/Readme.md
new file mode 100644
index 000000000..08d37a19a
--- /dev/null
+++ b/RationaleMCP/0035/Readme.md
@@ -0,0 +1,130 @@
+# Modelica Change Proposal MCP-0035
+# Multilingual support of Modelica
+## Authors: Anett Kloß, Gerd Kurzbach, Olaf Oelsner, Thomas Beutlich
+
+--
+
+# Summary
+Modelica currently supports only one language for description texts. This is usually English. In order to better support users from other language areas and to make Modelica libraries more attractive and easier to understand for them, it should be possible to provide translations of the texts in any language in a standardized form, so that tools can find, read and display them to the user in his or her preferred language.
+The definition of the interface to the translated texts is the subject of the MCP.
+
+In the discussion in [#302](https://github.com/modelica/ModelicaSpecification/issues/302) it was decided to provide the translation externally of the Modelica files using the [GNU gettext](https://www.gnu.org/software/gettext/) format. The use of this format in the Modelica context is described in the MCP.
+
+# Revisions
+| Date         | Description |
+| ------------ | --- |
+| 2021-06-14   | Anett Kloß: Prepared document based on ticket #302 |
+| 2022-01-07   | Gerd Kurzbach: add SpecificationText.md, some reformulations, discussion of design choices added |
+
+# Contributor License Agreement
+All authors of this MCP or their organizations have signed the "Modelica Contributor License Agreement". 
+
+# Rationale
+Why should this feature be included? 
+* A better understanding of the libraries by users with different language background will make the libraries more attractive. 
+* Support cases might occur less often, due to better understanding of the description. 
+* A new translation is additionally a review of the current state and can result in a better quality of both language versions.
+* Users can even write their own translation, when having a template *.pot-File for the library. 
+
+The use case for the proposal is the MSL 4.0. 
+* POT-File of current MSL 4.0 library --> this translation template is provided and filled for the Hydraulics Pump. 
+(*add pictures*)
+
+Proposed changes to the specification are described in SpecificationText.md. It consists of a new section **13.6 Multilingual Descriptions** which contains:
+* Where the translation files to be stored
+* How does a GNU gettext translation template for a library look like and which kind of descriptive texts shall be included?
+* Which strings should be translated:
+
+The precise updated text of the specification is part of this branch/pull-request: Yes.
+
+# Backwards Compatibility
+The proposal is backwards compatible. All multilingual text changes can be applied without effect at existing Modelica code. 
+After the introduction of translation files for libraries, this files need to be adjusted with every library change which adds new commented parts or changes existing comments.
+
+# Tool Implementation
+
+## Experience with Prototype
+### Implementation steps
+#### 1. Read out a translation template file
+Create at first a translation template file \*.pot for a Modelica library. Means a (tool dependent) readout of all needed text strings into a *LibraryName*.pot-File. It contains: 
+- a header which concludes all necessary information
+![Header of a *.pot file](POT_Header.png)
+
+- for all original strings entries with following structure: 
+```
+    msgctxt "Hydraulics.Basics.TankOverflow"
+    msgid "Volume Flow Port A"
+    msgstr ""
+```
+
+Where *msgctxt* contains the name of the Modelica Class and *msgid* contains the textstring which is situated in this name space and shall be translated. Please regard that if a *msgid* string (in this example "Volume Flow Port A") is given more than once in a namespace, all occurrences are translated with the same translation!
+
+It shall be mandatory to use for *msgctxt* the full name of a class:
+- so a specific translation depending on the content in this namespace is possible, as every textstring may differ depending on the context,
+- using the class makes it easier for the Modelica tool to copy and re-arrange models and packages without loosing the already existing language information.
+
+The following Modelica constructs shall be read out / translated: 
+* description strings
+* strings in following annotations:
+  * Text.string, Text.textString
+  * missingInnerMessage, obsolete, unassignedMessage 
+  * Dialog.[group|tab] 
+  * Dialog.[load|save]Selector.[caption|filter] 
+  * Documentation.[info|revisions]
+  * Figure.title, Plot.title, Curve.legend
+
+Having read out the file it just needs to be changed, if the library is changed (e.g. commented parts are added or changed or when having changed the Modelica name of the text strings containing element). 
+
+#### 2. Translation of the template file into a language file
+Starting from the template file create a \*.po file for each needed language (e.g. german: *LibraryName*.de.po-File).
+
+Edit the *msgstr* with the translation in the wanted language (here for german: `` Hydraulics.de.po``) :
+```
+    msgctxt "Hydraulics.Basics.TankOverflow"
+    msgid "Volume Flow Port A"
+    msgstr "Volumenstrom an Anschluss A"
+```
+
+Hereby no error shall occur if there is one comment not having a translation. In this case the not translated text (the content of *msgid*) shall be used.
+Again the file needs to be adjusted if there are changes at the library (e.g. commented parts are added or changed or when having changed the Modelica name of the text strings containing element).
+
+---
+**Note:** One may use the tool POedit for the translation, as it can be coupled with commercial translation tools for a faster translation. 
+
+---
+#### 3. File storage
+Both files need to be situated in the language directory ``Resources\Language`` of the top-level library e.g.:
+  ``C:\...\<ModelicaPath>\<LibraryName>\Resources\Language``
+#### 4. Read in the translation
+The tool dependent language setting enables the reading of the current needed *LibraryName*.*Language*.po-file.
+
+### Tool implementation effort 
+1. Readout of any comment / annotation without loosing content and with handling of exceptions, e.g. ``/"`` in comments. This can e.g. be created by the command:
+``xgettext --language=EmacsLisp --sort-output --extract-all --from-code=UTF-8 --output=TranslationTest.pot TranslationTest.mo``
+Certainly, the string extraction based on the EmacsLisp language can only be considered as proof of concept, since there is no Modelica language available in xgettext. It is recommended to create the POT file directly from the Modelica tool.
+
+2. When reading in a library read corresponding the *LibraryName*.*Language*.po-file into an internal table and lookup the translated strings just before presenting them to the user.
+
+## Discussion of the "One File per Library" design
+There is a design choice how to structure the files for translation information either
+* one file per library, or
+* one file per class.
+
+In this proposal the design "One file per library" is chosen, because it simplifies the handling of the translation data, the translation process and the generation of the template. The information of the header need to be stored only once. 
+
+If after finishing a library one wants to translate them into another language, he can use the preferred tool and feed the file as a whole into it. After translating the strings, he can then save the file and the work is done.
+
+
+One file per class, possibly stored in a directory structure that corresponds to the class hierarchy, result in a large number of files, with each file having to be translated separately. While this has the advantage of allowing parallel translations, it can also lead to undesirably different translations of the same texts, as different people translate things differently.
+
+Also a Modelica tool only has to take care of one file per library. Normally, for performance reasons, the information from the files is stored internally in one big table anyway, so there is no need to split the information.
+
+Multiple files have an advantage when renaming or moving classes, then the files only need to be renamed. The keyword msgctxt can then be omitted. In the case of only one file this can be realized by a search and replace of the msgctext information, which is not too complicated. The use case of moving classes in a finished library does not occur so often, because then also the models which use them must be adapted.
+
+
+# Required Patents
+None. 
+# References
+[GNU gettext](https://www.gnu.org/software/gettext/)
+
+[Poedit](https://poedit.net/) - useful editor 
diff --git a/RationaleMCP/0035/SpecificationText.md b/RationaleMCP/0035/SpecificationText.md
new file mode 100644
index 000000000..48a7b1efb
--- /dev/null
+++ b/RationaleMCP/0035/SpecificationText.md
@@ -0,0 +1,84 @@
+# 13.6 Multilingual Descriptions
+
+[*Descriptive texts in a model or library are usually formulated in English. To support users who are not so familiar with this, a Modelica tool can support the translation of these texts into any language. This should be done using external files, so that no modification of the actual Modelica text is required.*]
+
+The files to support translation must be provided by the developer of the library. They must be stored in a subdirectory of the Resources directory of the library with the name `Language`.
+
+Two kind of files have to be provided:
+* a template file `<LibraryName>.pot` (Portable Object Template). 
+It contains all necessary information to translate all descriptions, but no translations. The pattern `<LibraryName>` denotes the toplevel class name of the library.
+* one file for each supported language with the name `<LibraryName>.<language>.po` (Portable Object). This file is a copy of the associated template file, but extended with the translations in the specified language. The pattern `<language>` stands for the ISO 639-1 language code, e.g., de or sv.
+
+The files consist of a header and a body. All text strings are in double quotes and encoded with UTF-8 characters. Comments start with an `#` and are continued until the end of line. Spaces outside strings are ignored and used as separators. The detailed format of these files is described in [GNU gettext](https://www.gnu.org/software/gettext/manual/gettext.pdf).
+
+The header is marked with an empty msgid entry and looks like this:
+```
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the PACKAGE package.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2019-03-15 10:52+0100\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"Language: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+```
+All general terms in the header should be replaced by specific information.
+
+In the body, directly following the header, for each descriptive text there is an entry of the form
+```
+#: <file name>:<line number>
+msgctxt "<context identifier>"
+msgid "<descriptive text>"
+msgstr "<translation>"
+```
+Only the keywords `msgctxt`, `msgid` and `msgstr` are used.
+
+At first there can be an optional comment describing the location (file name and line number) of the text to translate. Multiple occurences of the same string can be listed here, separated by space.
+
+Then, the `<context identifier>` behind the keyword `msgctxt` is the full name of the Modelica class (e.g. `Modelica.Blocks.Math.Sin` ) where the text appears in. Short class definitions do not appear here. Texts in such classes (including their description string) belong to the enclosing full class definition.
+
+After the `msgid` keyword the text string which shall be translated follows. It should contain the original string from the Modelica text representation. 
+Since in Modelica control sequences also start with a backslash and another backslash is used to use sequences literally or to hide double quotes, no change is required here. 
+But Modelica allows strings to go over more than one line, gettext does not.
+Therefore, line breaks in Modelica must be encoded with "\n" for gettext.
+
+In order to avoid long lines Modelica strings may be split into consecutive strings at the line breaks, and the line breaks encoded with a "\n" at the end of each string, e.g.
+```
+"A
+B"
+```
+is converted to
+```
+"A\n"
+"B"
+```
+These strings are concatenated when read.
+[*Please regard that if a `msgid` string is given more than once in the same context, all occurrences are translated with the same (last) translation!*]
+
+The keyword `msgstr` is followed by the translation of `msgid`. With regard to control characters and line breaks, the same rules apply as for msgid. 
+In the template file this string is empty by definition. If this is empty in a language specific file the contents of `msgid` may be used instead.
+
+The texts in following Modelica constructs should be translated: 
+* description strings of component declarations and classes
+* strings in following annotations:
+  * Text.string, Text.textString
+  * missingInnerMessage, obsolete, unassignedMessage 
+  * Dialog.[group|tab] 
+  * Dialog.[load|save]Selector.[caption|filter] 
+  * Documentation.[info|revisions]
+  * Figure.title, Plot.title, Curve.legend
+
+C-style and line comments are not translated.
+
+[*To support the translation of these strings a number of free and commercial tools exist in context of GNU gettext. 
+A Modelica tool should provide a function to create the initial template file from an existing Modelica library.*]
diff --git a/RationaleMCP/Hints.md b/RationaleMCP/Hints.md
new file mode 100644
index 000000000..2b4fe88a5
--- /dev/null
+++ b/RationaleMCP/Hints.md
@@ -0,0 +1,13 @@
+Hints for generating a release.
+
+Currently there are no automated procedures for generating the revision-history.
+
+For the MCPs it is good to list additional pull requests considered, they can be found in GitHub's Pull Request list by searching for:
+```
+-base:master -base:maint/ is:merged
+```
+This can either be combined with limiting it to one MCP `label:MCP0035` or excluding some (earlier and later) MCPs `-label:MCP0031 -label:MCP0033`.
+Additionally it is good to list all pull request merged into the main branch after the latest release:
+```
+base:master merged:>=2020-12-31
+```
diff --git a/RationaleMCP/ReadMe.md b/RationaleMCP/ReadMe.md
index 517659d71..c58989e8a 100644
--- a/RationaleMCP/ReadMe.md
+++ b/RationaleMCP/ReadMe.md
@@ -24,15 +24,15 @@ but the rest of the development on a branch/pull-request before being accepted.
 |Active|0038|Initialization of Clocked Partitions|[MCP/0038](https://github.com/modelica/ModelicaSpecification/tree/MCP/0038/RationaleMCP/0038)||
 |Active|0037|Generalized Modelica URIs|[MCP/0037](https://github.com/modelica/ModelicaSpecification/tree/MCP/0037/RationaleMCP/0037)|https://github.com/modelica/ModelicaSpecification/pull/2663|
 |Active|0036|Setting states|[MCP/0036](https://github.com/modelica/ModelicaSpecification/tree/MCP/0036/RationaleMCP/0036)|https://github.com/modelica/ModelicaSpecification/pull/3164|
-|Active|0035|Multilingual support of Modelica|[MCP/0035](https://github.com/modelica/ModelicaSpecification/tree/MCP/0035/RationaleMCP/0035)|https://github.com/modelica/ModelicaSpecification/pull/2956|
+|Accepted in [3.6](https://github.com/modelica/ModelicaSpecification/releases/tag/v3.6)|0035|Multilingual support of Modelica|[MCP/0035](https://github.com/modelica/ModelicaSpecification/tree/MCP/0035/RationaleMCP/0035)|https://github.com/modelica/ModelicaSpecification/pull/2956|
 |Active|0034|Ternary|[MCP/0034](https://github.com/modelica/ModelicaSpecification/tree/MCP/0034/RationaleMCP/0034)|https://github.com/modelica/ModelicaSpecification/pull/2477|
 |Added in [3.5](https://github.com/modelica/ModelicaSpecification/releases/tag/v3.5)|0033|Annotations for Predefined Plots|[MCP/0033](https://github.com/modelica/ModelicaSpecification/tree/MCP/0033/RationaleMCP/0033)||
-|Active|0032|Selective Model Extension|[MCP/0032](https://github.com/modelica/ModelicaSpecification/tree/MCP/0032/RationaleMCP/0032)|https://github.com/modelica/ModelicaSpecification/pull/3166|
+|Accepted in [3.6](https://github.com/modelica/ModelicaSpecification/releases/tag/v3.6)|0032|Selective Model Extension|[MCP/0032](https://github.com/modelica/ModelicaSpecification/tree/MCP/0032/RationaleMCP/0032)|https://github.com/modelica/ModelicaSpecification/pull/3166|
 |Active|0031|Flat Modelica and MLS modularization|[MCP/0031](https://github.com/modelica/ModelicaSpecification/tree/MCP/0031/RationaleMCP/0031)|
 |On hold|0030|IsClocked Operator||[#2238](https://github.com/modelica/ModelicaSpecification/issues/2238)|
-|Active|0029|License Export|[MCP/0029](https://github.com/modelica/ModelicaSpecification/tree/MCP/0029/RationaleMCP/0029)||
+|Active|0029|License Export|[MCP/0029](https://github.com/modelica/ModelicaSpecification/tree/MCP/0029/RationaleMCP/0029)|https://github.com/modelica/ModelicaSpecification/pull/2900|
 |Added in [3.4](https://github.com/modelica/ModelicaSpecification/releases/tag/v3.4)|0028|Record Derivatives mixing Real and non-Real||[#2137](https://github.com/modelica/ModelicaSpecification/issues/2137)|
-|Active|0027|Units of Literal Constants|[MCP/0027](https://github.com/modelica/ModelicaSpecification/tree/MCP/0027/RationaleMCP/0027|[#3255](https://github.com/modelica/ModelicaSpecification/issues/3255) ([#2127](https://github.com/modelica/ModelicaSpecification/issues/2127))|
+|Active|0027|Units of Literal Constants|[MCP/0027](https://github.com/modelica/ModelicaSpecification/tree/MCP/0027/RationaleMCP/0027)|[#3255](https://github.com/modelica/ModelicaSpecification/issues/3255) ([#2127](https://github.com/modelica/ModelicaSpecification/issues/2127))|
 |Added in [3.4](https://github.com/modelica/ModelicaSpecification/releases/tag/v3.4)|0026|Arc-only Ellipse||[#2045](https://github.com/modelica/ModelicaSpecification/issues/2045)|
 |On hold|0025|Functions with input output||[#2012](https://github.com/modelica/ModelicaSpecification/issues/2012)|
 |Added in [3.4](https://github.com/modelica/ModelicaSpecification/releases/tag/v3.4)|0024|Initialization of Clocked States||[#2007](https://github.com/modelica/ModelicaSpecification/issues/2007)|
@@ -50,7 +50,7 @@ but the rest of the development on a branch/pull-request before being accepted.
 |Active|0012|Calling blocks as functions|[MCP/0012](https://github.com/modelica/ModelicaSpecification/tree/MCP/0012/RationaleMCP/0012)||
 |On hold|0011|Allow user-defined functions in reductions|||
 |On hold|0010|Adding guards to reductions|||
-|Active|0009|Undefined modification|[MCP/0009](https://github.com/modelica/ModelicaSpecification/tree/MCP/0009/RationaleMCP/0009)|https://github.com/modelica/ModelicaSpecification/pull/3167|
+|Accepted in [3.6](https://github.com/modelica/ModelicaSpecification/releases/tag/v3.6)|0009|Undefined modification|[MCP/0009](https://github.com/modelica/ModelicaSpecification/tree/MCP/0009/RationaleMCP/0009)|https://github.com/modelica/ModelicaSpecification/pull/3167|
 |On hold|0008|Custom annotations|||
 |On hold|0007|Match expressions|||
 |On hold|0006|Atomic blocks|||
diff --git a/chapters/annotations.tex b/chapters/annotations.tex
index 7056dd8e9..417d8b9ca 100644
--- a/chapters/annotations.tex
+++ b/chapters/annotations.tex
@@ -158,13 +158,15 @@ \subsubsection{Axis Properties}\label{axis-properties}
   Real max "Axis upper bound, in 'unit'";
   String unit = "" "Unit of axis tick labels";
   String label "Axis label";
+  AxisScale scale = Linear() "Mapping between axis values and position on axis"
 end Axis;
 \end{lstlisting}
 
 When an axis bound is not provided, the tool computes one automatically.
 
-An empty \lstinline!unit! means that the axis is unitless, and each expression plotted against it may use its own unit determined by the tool.  The tool is responsible for conveying the information
-about choice of unit for the different variables, for instance by attaching this information to curve legends.
+A non-empty \lstinline!unit! shall match \lstinline[language=grammar]!unit-expression! in \cref{unit-expressions}.
+An empty \lstinline!unit! means that the axis is unitless, and each expression plotted against it may use its own unit determined by the tool.
+The tool is responsible for conveying the information about choice of unit for the different variables, for instance by attaching this information to curve legends.
 
 The Modelica tool is responsible for showing that values at the axis tick marks are expressed in \lstinline!unit!, so the axis \lstinline!label! shall not contain this information.
 
@@ -180,6 +182,49 @@ \subsubsection{Axis Properties}\label{axis-properties}
 Variable replacements, as described in \cref{variable-replacements}, can be used in \lstinline!label!.
 The Modelica tool is responsible for showing the unit used for values at the axis tick marks, so the axis \lstinline!label! shall not contain the unit.
 
+The type of \lstinline!scale! is defined as an empty partial record:
+\begin{lstlisting}[language=modelica]
+partial record AxisScale
+end AxisScale;
+\end{lstlisting}%
+\annotationindex{AxisScale}
+
+The standardized annotations extending from \lstinline!AxisScale! are \lstinline!Linear! and  \lstinline!Log!, but it is also allowed to use a vendor-specific annotation.
+
+Use \lstinline!Linear! for a linear mapping between axis values and position on axis:
+\begin{lstlisting}[language=modelica]
+record Linear
+  extends AxisScale;
+end Linear;
+\end{lstlisting}%
+\index{Linear@\robustinline{Linear} (axis scale)}
+
+Use \lstinline!Log! for a logarithmic mapping between axis values and position on axis:
+\begin{lstlisting}[language=modelica]
+record Log
+  extends AxisScale;
+  Integer base(min = 2) = 10;
+end Log;
+\end{lstlisting}%
+\index{Log@\robustinline{Log} (axis scale)}
+
+The \lstinline!base! of a \lstinline!Log! scale determines preferred positions of major axis ticks.
+It is not required that the presentation of axis tick labels reflect the \lstinline!base! setting.
+For example, when \lstinline!base! is 10, major axis ticks should preferrably be placed at integer powers of 10, and natural alternatives that a tool may use for major axis tick labels could look like $0.001$ or $10^{-3}$.
+Under some circumstances, such as when the axis range does not span even a single order of magnitude, a tool may disregard the preference in order to get useful axis ticks.
+
+\begin{example}
+A \emph{symmetric log} axis scale is sometimes used for axes spanning across several orders of magnitude of both positive and negative values.
+Details vary, but the mapping from value to linear position along axis is some variation of $y \mapsto \operatorname{sign}(y)\, \operatorname{log}(1 + \frac{\abs{y}}{10^{\alpha}})$.
+A tool may implement this as a vendor-specific axis scale:
+\begin{lstlisting}[language=modelica]
+Axis(
+  min = -1e5, max = 1e5,
+  scale = __NameOfVendor_symlog(1),
+)
+\end{lstlisting}
+\end{example}
+
 \subsubsection{Plot Curves}\label{plot-curves}
 
 The actual data to plot is specified in the \lstinline!curves!\annotationindex{Curve} of a \lstinline!Plot!:
@@ -365,15 +410,48 @@ \section{Symbolic Processing}\label{annotations-for-symbolic-processing}\label{s
 The annotation \lstinline!Evaluate! can occur in the component declaration, its type declaration, or a base class of the type-declaration.
 In the case of multiple conflicting annotations it is handled similarly to modifiers (e.g., an \lstinline!Evaluate! annotation on the component declaration takes precedence).
 In the case of hierarchical components it is applied to all components, overriding any \lstinline!Evaluate!-setting for specific components.
-The annotation \lstinline!Evaluate! only has effect for a component declared with the prefix \lstinline!parameter!.
+The annotation \lstinline!Evaluate! is only allowed for parameters and constants.
 
-If \lstinline!Evaluate = true!, the model developer proposes to utilize the value for the symbolic processing. In that case, it is not possible to change the parameter value after symbolic pre-processing.
+Setting \lstinline!Evaluate = true! for an evaluable parameter, means that it must be an evaluated parameter (i.e., its value must be determined during translation, similar to a constant).
+For a non-evaluable parameter, it has no impact and it is recommended to issue a warning in most cases.
+The exception for recommending this warning is when the parameter is non-evaluable due to dependency on a parameter with \lstinline!Evaluate = false!, as this could be a sign of intentional overriding of \lstinline!Evaluate = true!, see example below.
+For both evaluable parameters and constants, the model developer further proposes to utilize the value for symbolic processing.
+A constant can never be changed after translation, and it is normal for its value to be used for symbolic processing even without \lstinline!Evaluate = true!.
 
-If \lstinline!Evaluate = false!, the model developer proposes to not utilize the value of the corresponding parameter for the symbolic processing.
+For a parameter, \lstinline!Evaluate = false! ensures that the parameter is a non-evaluable parameter according to \cref{component-variability} (meaning it is not allowed to be used where an evaluable expression (\cref{evaluable-expressions}) is expected).
+For both parameters and constants -- even when the value can be determined during translation -- the model developer further proposes to not utilize the value for symbolic processing.
 
 \begin{nonnormative}
-\lstinline!Evaluate! is for example used for axis of rotation parameters in the \lstinline!Modelica.Mechanics.MultiBody! library in order to improve the efficiency of the generated code.
+\lstinline!Evaluate = true! is for example used for axis of rotation parameters in the \lstinline!Modelica.Mechanics.MultiBody! library in order to improve the efficiency of the generated code.
+
+Conversely, a possible use of \lstinline!Evaluate = false! is to ensure that a parameter can be changed after translation, even when a tool might be tempted to evaluate it to improve the efficiency of the generated code.
 \end{nonnormative}
+
+\begin{example}
+When a parameter has \lstinline!Evaluate = true! for optimization reasons (not because it needs to be evaluable), it is possible to prevent the value from being determined during translation without modifying the original model:
+\begin{lstlisting}[language=modelica]
+model M_evaluable
+  /* Here, 'b' is evaluable, and will be evaluated. */
+  parameter Boolean b = false annotation(Evaluate = true);
+  Real x(start = 1.0, fixed = true);
+equation
+  if b then /* No need for b to be evaluable. */
+    der(x) = x;
+  else
+    der(x) = -x;
+  end if;
+end M_evaluable;
+
+model M_non_evaluable
+  /* Here, 'bn' is non-evaluable, which in turn will cause 'b' to be
+   * non-evaluable, thereby preventing it from being determined during
+   * translation.
+   */
+  extends M_evaluable(b = bn);
+  parameter Boolean bn = false annotation(Evaluate = false);
+end M_non_evaluable;
+\end{lstlisting}
+\end{example}
 \end{semantics}
 \end{annotationdefinition}
 
@@ -567,7 +645,7 @@ \section{Graphical Objects}\label{annotations-for-graphical-objects}\label{graph
 is no mechanism for defining an array of heterogeneous objects in Modelica.
 \end{nonnormative}
 
-These \lstinline!Icon!, \lstinline!Diagram!, and \lstinline!Documentation! annotations are only allowed directly in classes (e.g.\ not on components or connections).
+These \lstinline!Icon!, \lstinline!Diagram!, and \lstinline!Documentation! annotations are only allowed directly in classes (e.g., not on components or connections).
 The allowed annotations for a short class definition is the union of the allowed annotations in classes and on \lstinline!extends!-clauses.
 
 \subsection{Common Definitions}\label{common-definitions}
@@ -613,7 +691,7 @@ \subsubsection{Coordinate Systems}\label{coordinate-systems}
 application may use a different default value of \lstinline!initialScale!.
 
 The attribute \lstinline!grid! specifies the spacing between grid points which can
-be used by tools for alignment of points in the coordinate system, e.g.\ ``snap-to-grid''.
+be used by tools for alignment of points in the coordinate system, e.g., ``snap-to-grid''.
 Its use and default value is tool-dependent.
 
 \begin{lstlisting}[language=modelica]
@@ -630,7 +708,7 @@ \subsubsection{Coordinate Systems}\label{coordinate-systems}
 \begin{lstlisting}[language=modelica]
 CoordinateSystem(extent = {{-10, -10}, {10, 10}});
 \end{lstlisting}
-i.e.\ a coordinate system with width 20 units and height 20 units.
+i.e., a coordinate system with width 20 units and height 20 units.
 \end{example}
 
 The coordinate systems for the icon and diagram layers are by default defined as follows; where the array of \lstinline!GraphicItem! represents an ordered list of graphical primitives.
@@ -728,29 +806,29 @@ \subsection{Component Instance}\label{component-instance}
 
 A component instance can be placed within a diagram or icon layer.
 It has an annotation with a \lstinline!Placement! modifier to describe the placement.
-Placements are defined in term of coordinate systems transformations:
+Placements are defined in terms of coordinate system transformations:
 \begin{lstlisting}[language=modelica]
 record Transformation
-  Point origin = {0, 0};
   Extent extent;
   Real rotation(quantity = "angle", unit = "deg") = 0;
+  Point origin = {0, 0};
 end Transformation;
 \end{lstlisting}%
 \annotationindex{Transformation}
-The origin attribute defines the position of the component in the coordinate system of the enclosing class.
-The \lstinline!extent! defines the position, size and flipping of the component, relative to the \lstinline!origin! attribute.
-The \lstinline!extent! is defined relative to the \lstinline!origin! attribute of the component instance.
-Given an extent \lstinline!{{$x_{1}$, $y_{1}$}, {$x_{2}$, $y_{2}$}}!, $x_{2} < x_{1}$ defines horizontal flipping and $y_{2} < y_{1}$ defines vertical flipping around the center of the object.
-
-The \lstinline!rotation! attribute specifies rotation of the extent around the point defined by the \lstinline!origin! attribute.
-
-The graphical operations are applied in the order: scaling, flipping and rotation.
+The attributes are applied in the order \lstinline!extent!, \lstinline!rotation!, \lstinline!origin!, as follows:
+\begin{enumerate}
+\item
+  The \lstinline!extent! of the component icon is mapped to the \lstinline!extent! rectangle (possibly shifting, scaling, and flipping contents).
+\item
+  The \lstinline!rotation! specifies counter-clockwise rotation around the origin (that is \lstinline!{0, 0}!, not the \lstinline!origin! attribute).
+\item
+  The \lstinline!origin! specifies a shift (moving \lstinline!{0, 0}! to \lstinline!origin!).
+\end{enumerate}
 
 \begin{lstlisting}[language=modelica]
 record Placement
   Boolean visible = true;
   Transformation transformation "Placement in the diagram layer";
-
   Boolean iconVisible "Visible in icon layer; for public connector";
   Transformation iconTransformation
     "Placement in the icon layer; for public connector";
@@ -847,21 +925,19 @@ \subsection{Connections}\label{connections1}
 \end{example}
 
 The optional \lstinline!Text!\index{Text@\robustinline{Text}!\robustinline{connect} annotation} primitive defines a text that will be written on the connection line.
-It has the following definition (\emph{it is not equal to the \lstinline!Text! primitive as part of graphics -- the differences are marked as bold lines}):
-% NOTE: Technically just the names -- not the entire lines are marked in bold
+It has the following definition (it is not equal to the \lstinline!Text! primitive as part of graphics -- the differences are marked after \emph{Note} in the description-strings):
 \begin{lstlisting}[language=modelica]
 record Text
   extends GraphicItem;
-  extends FilledShape;
   Extent extent;
-  String string;
+  String string "Note: different name";
   Real fontSize = 0 "unit pt";
   String fontName;
   TextStyle textStyle[:];
-  Color textColor = lineColor;
+  Color textColor = Color.Black;
   TextAlignment horizontalAlignment =
-    if index < 0 then TextAlignment.Right else TextAligment.Left;
-  Integer index;
+    if index < 0 then TextAlignment.Right else TextAligment.Left "Note: different default";
+  Integer index "Note: new";
 end Text;
 \end{lstlisting}
 
@@ -877,11 +953,10 @@ \subsection{Connections}\label{connections1}
 connect(controlBus.axisControlBus1, axis1.axisControlBus)
   annotation(
     Text(string = "%first", index = -1, extent = [-6, 3; -6, 7]),
-    Line(points =
-      {{-80,-10},{-80,-14.5},{-79,-14.5},{-79,-17},{-65,-17},{-65,-65},{-25,-65}})
+    Line(points = {{41, 30}, {50, 30}, {50, 50}, {58, 50}})
   );
 \end{lstlisting}
-Draws a connection line and adds the text \emph{axisControlBus1} ending at $(-6,\, 3) + (-25,\, -65)$ and 4 vertical units of space for the text.
+Draws a connection line and adds the text \emph{axisControlBus1} ending at $(-6,\, 3) + (58,\, 50)$ and 4 vertical units of space for the text.
 Using a height of zero, such as \lstinline!extent = [-6, 3; -6, 3]! is deprecated, but gives similar result.
 \end{example}
 
@@ -988,20 +1063,18 @@ \subsubsection{Text}\label{text}
 \begin{lstlisting}[language=modelica]
 record Text
   extends GraphicItem;
-  extends FilledShape;
   Extent extent;
   String textString;
   Real fontSize = 0 "unit pt";
   String fontName;
   TextStyle textStyle[:];
-  Color textColor = lineColor;
+  Color textColor = Color.Black;
   TextAlignment horizontalAlignment = TextAlignment.Center;
 end Text;
 \end{lstlisting}%
 \annotationindex{Text}
 The \lstinline!textColor! attribute defines the color of the text.
 The text is drawn with transparent background and no border around the text (and without outline).
-The contents inherited from \lstinline!FilledShape! is deprecated, but kept for compatibility reasons.
 
 There are a number of common macros that can be used in the text, and they should be replaced when displaying the text as follows (in order such that the earliest ones have precedence, and using the longest sequence of identifier characters -- alphanumeric and underscore):
 \begin{itemize}
@@ -1669,7 +1742,7 @@ \subsubsection{Conversion Rules}\label{conversion-rules}
 corresponding to the old version.
 
 \begin{nonnormative}
-Whenever possible tools should preserve the original style of the model, e.g.\ use of imports.
+Whenever possible tools should preserve the original style of the model, e.g., use of imports.
 Conversions should be applied in all places where named element are used in code, including Modelica URIs (for example, in \lstinline!Documentation! annotations).
 \end{nonnormative}
 
@@ -1677,7 +1750,7 @@ \subsubsection{Conversion Rules}\label{conversion-rules}
 and vectorize according to \cref{scalar-functions-applied-to-array-arguments}.
 
 All of these convert-functions only use inheritance among user models, and not in the library that is used for the conversion -- thus conversions of base classes will require multiple conversion calls; this ensures that the conversion is independent of the new library structure.
-The name of the class used as argument to \lstinline!convertElement! and \lstinline!convertModifiers! is similarly the old name of the class, i.e.\ the name before it is possibly converted by \lstinline!convertClass!.
+The name of the class used as argument to \lstinline!convertElement! and \lstinline!convertModifiers! is similarly the old name of the class, i.e., the name before it is possibly converted by \lstinline!convertClass!.
 
 \begin{nonnormative}
 Specifying conversions using the old name of a class allows the conversion to be done without access to the old
@@ -1698,7 +1771,7 @@ \subsubsection{Conversion Rules}\label{conversion-rules}
 convertClass("Modelica.SIunits.Icons", "Modelica.Units.Icons");
 \end{lstlisting}
 This ensures that for example \lstinline!Modelica.SIunits.Length! is converted to \lstinline!Modelica.Units.SI.Length!
-and \lstinline!Modelica.SIunits.Icons! is converted to \lstinline!Modelica.SIunits.Icons!.
+and \lstinline!Modelica.SIunits.Icons! is converted to \lstinline!Modelica.Units.Icons!.
 \end{example}
 
 \paragraph*{convertClassIf("OldClass", "oldElement", "whenValue", "NewClass")}\label{convertclassifoldclass-oldelement-whenvalue-newclass}\annotationindex{convertClassIf}
@@ -1711,7 +1784,7 @@ \subsubsection{Conversion Rules}\label{conversion-rules}
 
 The old element should be of a \lstinline!Boolean!, \lstinline!Integer!, \lstinline!String!, or enumeration
 type and the match is based on the literal value of the modifier.
-For string elements the value argument to \lstinline!convertClassIf! shall be up-quoted, e.g.\ \lstinline!"\"My String\""!,
+For string elements the value argument to \lstinline!convertClassIf! shall be up-quoted, e.g., \lstinline!"\"My String\""!,
 and for enumeration literals only the enumeration literal part of the old value matters, e.g., \lstinline!red!
 for \lstinline!"Colors.red"!.
 
@@ -1799,7 +1872,7 @@ \subsubsection{Conversion Rules}\label{conversion-rules}
 connector \lstinline!B! is connected, there will be a parameter for enabling connector \lstinline!B!, and the conversion ensures that
 each component of model \lstinline!A! will have this parameter set accordingly.
 
-In case a parameter is simply renamed it is preferable to use \lstinline!convertElement!, since that also handles e.g.\ binding equations
+In case a parameter is simply renamed it is preferable to use \lstinline!convertElement!, since that also handles, e.g., binding equations
 using the parameter.
 \end{nonnormative}
 
@@ -1920,9 +1993,9 @@ \subsection{Version Date and Build Information}\label{version-date-and-build-inf
 \annotationindex{versionDate}\annotationindex{versionBuild}\annotationindex{dateModified}\annotationindex{revisionId}
 
 \begin{example}
-\begin{lstlisting}[language=modelica,mathescape=false]
+\begin{lstlisting}[language=modelica,mathescape=false,escapechar=!]
 package Modelica
-  $\ldots$
+  !\ldots!
   annotation(
     version = "3.0.1",
     versionDate = "2008-04-10",
@@ -1976,7 +2049,7 @@ \subsection{Version Date and Build Information}\label{version-date-and-build-inf
   \end{nonnormative}
 \item
   \lstinline!revisionId! is a tool specific revision identifier
-  possibly generated by a source code management system (e.g.\ Subversion
+  possibly generated by a source code management system (e.g., Subversion
   or CVS). This information exactly identifies the library
   source code in the source code management system.
 \end{itemize}
@@ -2023,7 +2096,7 @@ \section{Access Control to Protect Intellectual Property}\label{annotations-for-
 \end{definition}
 
 \begin{definition}[Obfuscation]\index{obfuscation!access control}
-Changing a Modelica class or generated code so that it is difficult to inspect by a user (e.g.\ by automatically renaming variables to non-meaningful names).
+Changing a Modelica class or generated code so that it is difficult to inspect by a user (e.g., by automatically renaming variables to non-meaningful names).
 \end{definition}
 
 \begin{definition}[Encryption]\index{encryption!access control}
@@ -2186,7 +2259,7 @@ \subsection{Licensing}\label{licensing}
 
 record License
   String licensee = "" "Optional string to show information about the licensee";
-  String id[:] "Unique machine identifications, e.g.\ MAC addresses";
+  String id[:] "Unique machine identifications, e.g., MAC addresses";
   String features[:] = fill("", 0) "Activated library license features";
   String startDate = "" "Optional start date in UTCformat YYYY-MM-DD";
   String expirationDate = "" "Optional expiration date in UTCformat YYYY-MM-DD";
diff --git a/chapters/arrays.tex b/chapters/arrays.tex
index 03323f8c1..00f8ccd75 100644
--- a/chapters/arrays.tex
+++ b/chapters/arrays.tex
@@ -40,7 +40,7 @@ \section{Array Declarations}\label{array-declarations}
 The following table shows the two possible forms of declarations and defines the terminology.
 % Is the use of "class" here meant to exclude types defined as array aliases (see comment in table below)?
 \lstinline!C! is a placeholder for any class, including the built-in type classes \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, \lstinline!String!, and enumeration types.
-The type of a dimension upper bound expression, e.g.\ $n$, $m$, $p$, \ldots in the table below, need to be a subtype of \lstinline!Integer! or \lstinline!EB! for a class \lstinline!EB! that is an enumeration type or subtype of the \lstinline!Boolean! type.
+The type of a dimension upper bound expression, e.g., $n$, $m$, $p$, \ldots in the table below, need to be a subtype of \lstinline!Integer! or \lstinline!EB! for a class \lstinline!EB! that is an enumeration type or subtype of the \lstinline!Boolean! type.
 
 Colon (\lstinline!:!) indicates that the dimension upper bound is unknown and is a subtype of \lstinline!Integer!.
 The size of such a variable can be determined from its binding equation, or the size of any of its array attributes, see also \cref{flexible-array-sizes-and-resizing-of-arrays-in-functions}.
@@ -51,7 +51,7 @@ \section{Array Declarations}\label{array-declarations}
 An array indexed by \lstinline!Boolean! or enumeration type can only be used in the following ways:
 \begin{itemize}
 \item
-  Subscripted using expressions of the appropriate type (i.e.\ \lstinline!Boolean! or the enumerated type).
+  Subscripted using expressions of the appropriate type (i.e., \lstinline!Boolean! or the enumerated type).
 \item
   Binding equations of the form \lstinline!x1 = x2! are allowed for arrays independent of whether the index types of dimensions are subtypes of \lstinline!Integer!, \lstinline!Boolean!, or enumeration types.
 \end{itemize}
@@ -227,7 +227,7 @@ \section{Built-in Array Functions}\label{built-in-array-functions}
 
 The argument $n$ must be a constant that can be evaluated during translation, as it determines the number of dimensions of the returned array.
 \begin{nonnormative}
-An $n$ that is not a constant that can be evaluated during translation for \lstinline!promote! complicates matrix handling as it can change matrix-equations in subtle ways (e.g.\ changing inner products to matrix multiplication).
+An $n$ that is not a constant that can be evaluated during translation for \lstinline!promote! complicates matrix handling as it can change matrix-equations in subtle ways (e.g., changing inner products to matrix multiplication).
 \end{nonnormative}
 \end{semantics}
 \end{operatordefinition}
@@ -580,6 +580,7 @@ \subsubsection{Reduction Expressions}\label{reduction-expressions}
 is a \firstuse{reduction expression}.
 The expressions in the iterators of a reduction expression shall be vector expressions.
 They are evaluated once for each reduction expression, and are evaluated in the scope immediately enclosing the reduction expression.
+If \lstinline!expression1! contains event-generating expressions, the expressions inside the iterators shall be evaluable.
 
 For an iterator:
 \begin{lstlisting}[language=grammar]
@@ -753,6 +754,7 @@ \subsection{Constructor with Iterators}\label{array-constructor-with-iterators}\
 \end{lstlisting}
 is an \firstuse[array!constructor!with iterators]{array constructor with iterators}.
 The expressions inside the iterators of an array constructor shall be vector expressions.
+If \lstinline!expression! contains event-generating expressions, the expressions inside the iterators shall be evaluable.
 They are evaluated once for each array constructor, and are evaluated in the scope immediately enclosing the array constructor.
 
 For an iterator:
@@ -860,7 +862,7 @@ \subsubsection{Concatenation along First and Second Dimensions}\label{array-conc
 \item
   \lstinline![A] = promote(A, max(2, ndims(A)))!, i.e., \lstinline![A] = A!, if \lstinline!A! has 2 or more dimensions, and it is a matrix with the elements of \lstinline!A!, if \lstinline!A! is a scalar or a vector.
 \item
-  There must be at least one argument (i.e.\ \lstinline![]! is not defined).
+  There must be at least one argument (i.e., \lstinline![]! is not defined).
 \end{itemize}
 
 \begin{example}
@@ -1268,10 +1270,23 @@ \subsection{Element-wise Division}\label{array-element-wise-division}\label{elem
 
 \subsection{Element-wise Exponentiation}\label{element-wise-exponentiation}
 
-Exponentiation \lstinline!a ^ b! is defined as \lstinline[language=C]!pow(double a, double b)! in the ANSI~C library if both \lstinline!a! and \lstinline!b! are
-\lstinline!Real! scalars. A \lstinline!Real! scalar value is returned.  If \lstinline!a! or \lstinline!b! are \lstinline!Integer! scalars, they are
-automatically promoted to \lstinline!Real!.  Consequences of exceptional situations, such as ($\text{\lstinline!a!} = 0.0$ and $\text{\lstinline!b!} \leq 0.0$,
-$\text{\lstinline!a!} < 0$ and \lstinline!b! is not an integer) or overflow are undefined.
+Exponentiation \lstinline!a ^ b! always returns a \lstinline!Real! scalar value, and it is required that \lstinline!a! and \lstinline!b! are scalar \lstinline!Real! or \lstinline!Integer! expressions.
+The result should correspond to mathematical exponentiation with the following special cases:
+\begin{itemize}
+\item For any value of \lstinline!a! (including $0.0$) and an \lstinline!Integer! $\text{\lstinline!b!} = 0$, the result is $1.0$.
+\item If $\text{\lstinline!a!} < 0$ and \lstinline!b! is an \lstinline!Integer!, the result is defined as $\pm |a|^b$, with sign depending on whether \lstinline!b! is even (positive) or odd (negative).
+\item A deprecated semantics is to treat $\text{\lstinline!a!} < 0$ and a \lstinline!Real! \lstinline!b! having a non-zero integer value as if \lstinline!b! were an \lstinline!Integer!.
+\item For $\text{\lstinline!a!} = 0$ and $\text{\lstinline!b!} > 0$, the result is $0.0$.
+\item
+  Other exceptional situations are illegal.
+  For example: $\text{\lstinline!a!} = 0.0$ and $\text{\lstinline!b!} = 0.0$ for a \lstinline!Real b!, $\text{\lstinline!a!} = 0.0$ and $\text{\lstinline!b!} < 0$, or $\text{\lstinline!a!} < 0$ and \lstinline!b! does not have an integer value.
+\end{itemize}
+
+\begin{nonnormative}
+Except for defining the special case of $0.0^0$ it corresponds to \lstinline[language=C]!pow(double a, double b)! in the ANSI~C library.
+The result is always \lstinline!Real! as negative exponents can give non-integer results also when both operands are \lstinline!Integer!.
+The special treatment of \lstinline!Integer! exponents makes it possible to use $x^n$ in a power series.
+\end{nonnormative}
 
 Element-wise exponentiation \lstinline!a .^ b! of numeric scalars, vectors, matrices, or arrays \lstinline!a! and \lstinline!b! requires a numeric type class for
 \lstinline!a! and \lstinline!b! and either \lstinline!size(a) = size(b)! or scalar \lstinline!a! or scalar \lstinline!b!.
@@ -1299,7 +1314,7 @@ \subsection{Element-wise Exponentiation}\label{element-wise-exponentiation}
 2.^[1, 2; 3, 4]  // error; same as 2.0 ^ [1, 2; 3, 4]
 2 .^[1, 2; 3, 4] // fine; element-wise exponentiation
 \end{lstlisting}
-This is a consequence of the parsing rules, i.e.\ since \lstinline!2.! could be a lexical unit it seen as a lexical unit; using a space after
+This is a consequence of the parsing rules, i.e., since \lstinline!2.! could be a lexical unit it seen as a lexical unit; using a space after
 literals solves the problem.
 \end{example}
 
@@ -1330,7 +1345,7 @@ \subsection{Slice Operation}\label{slice-operation}
 \item
   If \lstinline!m! is also an array component, the slice operation is valid only if \lstinline!size(a[1].m)! = \lstinline!size(a[2].m)! = \ldots
 \item
-  The slicing operation can be combined with indexing, e.g.\ \lstinline!a.m[1]!.  It returns the array of components \lstinline!{a[1].m[1], a[2].m[1], $\ldots$}!,
+  The slicing operation can be combined with indexing, e.g., \lstinline!a.m[1]!.  It returns the array of components \lstinline!{a[1].m[1], a[2].m[1], $\ldots$}!,
   and does not require that \lstinline!size(a[1].m) = size(a[2].m)!.  The number of subscripts on \lstinline!m! must not be greater than the number of array dimension
   for \lstinline!m! (the number can be smaller, in which case the missing trailing indices are assumed to be `\lstinline!:!'), and is only valid if
   \lstinline!size(a[1].m[$\ldots$]) = size(a[2].m[$\ldots$])!.
diff --git a/chapters/classes.tex b/chapters/classes.tex
index 1301951d0..289497d81 100644
--- a/chapters/classes.tex
+++ b/chapters/classes.tex
@@ -46,7 +46,7 @@ \section{Access Control -- Public and Protected Elements}\label{access-control-p
 \end{example}
 
 All elements defined under the heading \lstinline!protected! are regarded as protected.  All other elements (i.e., defined
-under the heading \lstinline!public!, without headings or in a separate file) are public (i.e.\ not protected).  Regarding
+under the heading \lstinline!public!, without headings or in a separate file) are public (i.e., not protected).  Regarding
 inheritance of protected and public elements, see \cref{inheritance-of-protected-and-public-elements}.
 
 
@@ -130,7 +130,7 @@ \subsection{Syntax}\label{component-declaration-syntax}\label{syntax-and-example
 
 \begin{nonnormative}
 The declaration of a component states the type, access, variability, data flow, and other properties of the component.
-A \lstinline[language=grammar]!component-clause! i.e., the whole declaration, contains type prefixes followed by a \lstinline[language=grammar]!type-specifier! with optional \lstinline[language=grammar]!array-subscripts! followed by a \lstinline[language=grammar]!component-list!.
+A \lstinline[language=grammar]!component-clause!, i.e., the whole declaration, contains type prefixes followed by a \lstinline[language=grammar]!type-specifier! with optional \lstinline[language=grammar]!array-subscripts! followed by a \lstinline[language=grammar]!component-list!.
 
 There is no semantic difference between variables declared in a single declaration or in multiple declarations.
 For example, regard the following single declaration (\lstinline[language=grammar]!component-clause!) of two matrix variables:
@@ -164,6 +164,7 @@ \subsection{Static Semantics}\label{component-declaration-static-semantics}
 % Seems sufficient to just have \indexinline variant of 'partial' in index.
 A class defined with \lstinline!partial!\indexinline{partial} in the \lstinline[language=grammar]!class-prefixes! is called a \firstuse[---]{partial} class.
 Such a class is allowed to be incomplete, and cannot be instantiated in a simulation model; useful, e.g., as a base class.
+See \cref{short-class-definitions} regarding short class definition semantics of propagating \lstinline!partial!.
 
 If the \lstinline[language=grammar]!type-specifier! of the component does not denote a built-in type, the name of the type is looked up (\cref{static-name-lookup}).
 The found type is flattened with a new environment and the partially flattened enclosing class of the component.
@@ -177,7 +178,8 @@ \subsection{Static Semantics}\label{component-declaration-static-semantics}
 \end{itemize}
 in that order.
 
-Array dimensions shall be scalar non-negative parameter expressions of type \lstinline!Integer!, a reference to a type (which must an enumeration type or \lstinline!Boolean!, see \cref{enumeration-types}), or the colon operator denoting that the array dimension is left unspecified (see \cref{array-declarations}).  All variants can also be part of short class definitions.
+Array dimensions shall be scalar non-negative evaluable expressions of type \lstinline!Integer!, a reference to a type (which must an enumeration type or \lstinline!Boolean!, see \cref{enumeration-types}), or the colon operator denoting that the array dimension is left unspecified (see \cref{array-declarations}).
+All variants can also be part of short class definitions.
 
 \begin{example}
 Variables with array dimensions:
@@ -224,7 +226,8 @@ \subsubsection{Prefix Rules}\label{prefix-rules}
 
 In addition, instances of classes extending from \lstinline!ExternalObject! may have type prefixes \lstinline!parameter! and \lstinline!constant!, and in functions also type prefixes \lstinline!input! and \lstinline!output!, see \cref{external-objects}.
 
-Variables declared with the \lstinline!stream! type prefix shall be a subtype of \lstinline!Real!.
+Variables declared with the \lstinline!stream! type prefix shall be a subtype of \lstinline!Real!, or a \lstinline!record! component where all the primitive elements shall be a subtype of \lstinline!Real!.
+The members of the record may not have the \lstinline!stream! type prefix.
 This is further restricted in \cref{definition-of-stream-connectors}.
 
 Variables declared with the \lstinline!input! type prefix must not also have the prefix \lstinline!parameter! or \lstinline!constant!.
@@ -239,7 +242,7 @@ \subsubsection{Prefix Rules}\label{prefix-rules}
 
 \begin{nonnormative}
 The prefixes \lstinline!flow!, \lstinline!stream!, \lstinline!input! and \lstinline!output! could be treated more uniformly above, and instead rely on other rules forbidding combinations.
-The type prefix \lstinline!stream! cannot be applied to structured components.
+The type prefix \lstinline!stream! can be applied to structured components, specifically records.
 The type prefix \lstinline!flow! can be applied to structured components, see \cref{generation-of-connection-equations}.
 Note that there are no specific restrictions if an operator record component has the type prefix \lstinline!flow!, since the members of an operator record cannot have any of the prefixes \lstinline!flow!, \lstinline!stream!, \lstinline!input! or \lstinline!output!.
 \end{nonnormative}
@@ -296,37 +299,58 @@ \subsubsection{Prefix Rules}\label{prefix-rules}
   function.
 \end{itemize}
 
+
+\subsection{Component Variability Prefixes}\label{component-variability-prefixes-discrete-parameter-constant}
+
+The prefixes \lstinline!discrete!, \lstinline!parameter!, \lstinline!constant! of a component declaration are called \firstuse[variability!prefix]{variability prefixes} and are the basis for defining in which situation the variable values of a component are initialized (see \cref{events-and-synchronization} and \cref{initialization-initial-equation-and-initial-algorithm}) and when they are changed during simulation.
+Further details on how the prefixes relate to component variability, as well as rules applying to components the different variabilities, are given in \cref{component-variability}.
+
+
 \subsection{Acyclic Bindings of Constants and Parameters}\label{acyclic-bindings-of-constants-and-parameters}
 
-The unexpanded binding equations for parameters and constants in the translated model must be acyclic after flattening; except that cycles are allowed if the cycles disappear when evaluating parameters having annotation \lstinline!Evaluate = true! that are not part of the cycle.
-Thus it is not possible to introduce equations for parameters by cyclic dependencies.
+For a constant or parameter \lstinline!v! with declaration equation, the expression of the declaration equation in the flattended model must not depend on \lstinline!v! itself, neither directly nor indirectly via other variables' declaration equations.
+To satisfy this condition, dependencies shall be removed as needed by applying simplifications based on values of constants (except with \lstinline!Evaluate = false!) and all other \willintroduce{evaluable parameters} (\cref{component-variability}) that don't depend on \lstinline!v!.
+It is not permitted to expand a non-scalar declaration equation into scalar equations to satisfy the condition.
 
-\begin{nonnormative}
-There is no exception for parameters with \lstinline!fixed = false!, despite the fact that such parameters are generally allowed to be initialized from systems of dependent equations.
-% Saying "binding equation" below even though it's called a "declaration equation", for consistency with the normative paragraph above.
-However, a parameter with \lstinline!fixed = false! can use an initial equation instead of a binding equation, allowing for cyclic dependencies.
-\end{nonnormative}
+That the value of an evaluable parameter is used for these simplifications does not mean that it has to be determined during translation, but if \lstinline!v! is found to be an evaluable parameter, then a Modelica tool will be able to break all cycles involving \lstinline!v! by making some (possibly none or all) of the other evaluable parameters determined during translation.
+Hence, evaluation of a constant or evaluable parameter can never require solving systems of equations; they can always be sorted so that they can be solved one at a time with the natural causality (i.e., the declaration equation is used to determine the value of the component to which it belongs).
 
 \begin{example}
+Direct and indirect cyclic dependency:
 \begin{lstlisting}[language=modelica]
-constant Real p = 2 * q;
-constant Real q = sin(p); // Illegal since p = 2 * q, q = sin(p) are cyclical
+/* All of the following are illegal: */
+parameter Real r = 2 * sin(r); // Depends directly on r.
+parameter Real p = 2 * q;      // Indirect dependency on p via q = sin(p).
+parameter Real q = sin(p);     // Indirect dependency on q via p = 2 * q.
+\end{lstlisting}
+\end{example}
 
+\begin{example}
+While declaration equations must not be cyclical, the use of initial equations can still introduce valid cyclic dependencies between parameters:
+\begin{lstlisting}[language=modelica]
+  parameter Real p = 2 * q; // This is the only declaration equation.
+  parameter Real q(fixed = false);
+initial equation
+  q = sin(p); // OK, not a declaration equation.
+\end{lstlisting}
+\end{example}
+
+\begin{example}
+Breaking cyclic dependency.
+\begin{lstlisting}[language=modelica]
 model ABCD
   parameter Real A[n, n];
   parameter Integer n = size(A, 1);
 end ABCD;
 
 final ABCD a;
-// Illegal since cyclic dependencies between size(a.A,1) and a.n
+// Illegal cyclic dependency between size(a.A, 1) and a.n.
 
 ABCD b(redeclare Real A[2, 2] = [1, 2; 3, 4]);
 // Legal since size of A is no longer dependent on n.
 
 ABCD c(n = 2); // Legal since n is no longer dependent on the size of A.
 
-parameter Real r = 2 * sin(r); // Illegal, since r = 2 * sin(r) is cyclic
-
 partial model PartialLumpedVolume
   parameter Boolean use_T_start = true "= true, use T_start, otherwise h_start"
     annotation(Dialog(tab = "Initialization"), Evaluate = true);
@@ -337,10 +361,10 @@ \subsection{Acyclic Bindings of Constants and Parameters}\label{acyclic-bindings
       Medium.specificEnthalpy_pTX(p_start, T_start, X_start) else Medium.h_default
     annotation(Dialog(tab = "Initialization", enable = not use_T_start));
 end PartialLumpedVolume;
-// Cycle for T_start and h_start, but ok since disappears
+// Cycle for T_start and h_start, but still valid since cycle disappears
 // when evaluating use_T_start
 
-// Illegal since the unexpanded bindings have cycles for both x and y
+// The unexpanded bindings have illegal cycles for both x and y
 // (even if they would disappear if bindings were expanded).
 model HasCycles
   parameter Integer n = 10;
@@ -351,62 +375,98 @@ \subsection{Acyclic Bindings of Constants and Parameters}\label{acyclic-bindings
 \end{lstlisting}
 \end{example}
 
-\subsection{Component Variability Prefixes}\label{component-variability-prefixes-discrete-parameter-constant}
 
-The prefixes \lstinline!discrete!, \lstinline!parameter!, \lstinline!constant! of a component declaration are called \firstuse[variability!prefix]{variability prefixes}\index{component variability}\index{declared variability}\index{variability!declared|see{declared variability}} and define in which situation the variable values of a component are initialized (see \cref{events-and-synchronization} and \cref{initialization-initial-equation-and-initial-algorithm}) and when they are changed during simulation:
+\subsection{Conditional Component Declaration}\label{conditional-component-declaration}
+
+A component declaration can have a \lstinline!condition-attribute!: \lstinline!if!~\emph{expression}.
+
+\begin{example}
+\begin{lstlisting}[language=modelica]
+  parameter Integer level(min=1)=1;
+  Motor motor;
+  Level1 component1(J=J) if level==1 "Conditional component";
+  Level2 component2 if level==2 "Conditional component";
+  Level3 component3(J=component1.J) if level<2 "Conditional component";
+  // Illegal modifier on component3 since component1.J is conditional
+  // Even if we can see that component1 always exist if component3 exist
+equation
+  connect(component1$\ldots$, $\ldots$) "Connection to conditional component 1";
+  connect(component2.n, motor.n) "Connection to conditional component 2";
+  connect(component3.n, motor.n) "Connection to conditional component 3";
+  component1.u=0; // Illegal
+\end{lstlisting}
+\end{example}
+
+The \emph{expression} must be a \lstinline!Boolean! scalar expression, and must be a parameter expression.
+
+\begin{nonnormative}
+A parameter expression is required since it shall be evaluated at compile time.
+\end{nonnormative}
+
+A redeclaration of a component shall not include a condition attribute;
+and the condition attribute is kept from the original declaration (see
+\cref{interface-compatibility-or-subtyping}).
+
+If the \lstinline!Boolean! expression is false the component (including its modifier) is removed from the flattened DAE, and connections to/from the component are removed.
+A component declared with a condition-attribute can only be modified and/or used in connections.
+
+\begin{nonnormative}
+Adding the component and then removing it ensures that the component is valid.
+
+If a connect equation defines the connection of a non-conditional component \lstinline!c1! with a conditional component \lstinline!c2! and \lstinline!c2! is de-activated, then \lstinline!c1! must still be a declared element.
+
+There are annotations to handle the case where the connector should be connected when activated, see \cref{annotations-for-the-graphical-user-interface}.
+\end{nonnormative}
+
+
+\section{Component Variability}\label{component-variability}
+
+As briefly mentioned in \cref{component-variability-prefixes-discrete-parameter-constant}, the component variability prefixes are the basis for defining \firstuse{component variability}\index{declared variability}\index{variability!declared|see{declared variability}}.
+Combined with some other information about the components and analysis of expression variability (\cref{variability-of-expressions}), they define the component variabilities as follows:
 \begin{itemize}
 \item
-  A variable \lstinline!vc! declared with \lstinline!constant!\indexinline{constant} prefix remains constant during simulation, with a value that is unaffected even by the initialization problem.
+  A variable \lstinline!vc! declared with \lstinline!constant!\indexinline{constant} prefix does not change during simulation, with a value that is unaffected even by the initialization problem (i.e., determined during translation).
   This is called a \firstuse[---]{constant}, or \firstuse[constant!variable]{constant variable}\index{component variability!constant}.
+  For further details, see \ref{constants}.
 \item
-  A variable \lstinline!vc! declared with the \lstinline!parameter!\indexinline{parameter} prefix has a value determined at initialization, and keeps that value during the entire simulation.
-  Thus it is known and non-changing during transient analysis.
-  This is called a \firstuse[---]{parameter}, or \firstuse[parameter!variable]{parameter variable}\index{component variability!parameter}.
+  A variable \lstinline!ep! is called a \firstuse[parameter!evaluable]{evaluable parameter variable}\index{component variability!evaluable parameter} if all of the following applies:
+  \begin{itemize}
+  \item
+    It is declared with the \lstinline!parameter!\indexinline{parameter} prefix.
+  \item
+    It has \lstinline!fixed = true!.
+  \item
+    It does not have annotation \lstinline!Evaluate = false!.
+  \item
+    The declaration equation -- or \lstinline!start!-attribute if no declaration equation is given (see \cref{initialization-initial-equation-and-initial-algorithm}) -- is given by an evaluable expression (\cref{evaluable-expressions}).
+  \end{itemize}
+  It is also simply called an \firstuse[---]{evaluable parameter}.
+  An evaluable parameter does not change during transient analysis, with a value either determined during translation (similar to having prefix \lstinline!constant!, and is then called an \firstuse[parameter!evaluated]{evaluated parameter}) or by the initialization problem (similar to a \willintroduce{non-evaluable parameter}, see item below).
+  At which of these stages the value is determined is tool dependent.
+  For further details, see \ref{parameters}.
+\item
+  A variable \lstinline!np! declared with the \lstinline!parameter!\indexinline{parameter} prefix, is called a \firstuse[parameter!non-evaluable]{non-evaluable parameter variable}\index{component variability!non-evaluable parameter} unless it is an evaluable parameter.
+  It is also simply called a \firstuse[---]{non-evaluable parameter}.
+  It does not change during transient analysis, with a value determined by the initialization problem.
+  For further details, see \ref{parameters}.
 \item
   A \firstuse[discrete-time!variable]{discrete-time variable}\index{component variability!discrete-time} \lstinline!vd! is a variable that is discrete-valued (that is, not of \lstinline!Real! type) or assigned in a \lstinline!when!-clause.
   The \lstinline!discrete!\indexinline{discrete} prefix may be used to clarify that a variable is discrete-time.
-  It has a vanishing time derivative between events.
-  Note that this is not the same as saying that \lstinline!der(vd)=0! almost everywhere, as the derivative is not even defined at the events.
-  It is not allowed to apply \lstinline!der! to discrete-time variables.
   During transient analysis the variable can only change its value at event instants (see \cref{events-and-synchronization}).
+  For further details, see \ref{discrete-time-variables}.
 \item
   A \firstuse[continuous-time!variable]{continuous-time variable}\index{component variability!continuous-time} is a \lstinline!Real! variable without any prefix that is not assigned in a \lstinline!when!-clause.
-  A continuous-time variable \lstinline!vn! may have a non-vanishing time derivative (provided \lstinline!der(vn)! is allowed this can be expressed as \lstinline!der(vn) <> 0!) and may also change its value discontinuously at any time during transient analysis (see \cref{events-and-synchronization}).
-  It may also contain a combination of these effects.
-  Regarding existence of \lstinline!der(vn)!, see \cref{modelica:der}.
+  The variable can change both continuously and discontinuously at any time.
+  For further details, see \ref{continuous-time-variables}.
 \end{itemize}
 
-Components declared as \lstinline!constant! shall have an associated declaration equation with a constant expression, if the constant is directly in the simulation model, or used in the simulation model.
-The value of a constant can be modified after it has been given a value, unless the constant is declared \lstinline!final! or modified with a \lstinline!final! modifier.
-A constant without an associated declaration equation can be given one by using a modifier.
-
-If a \lstinline!Real! variable is declared with the prefix \lstinline!discrete!\indexinline{discrete} it must in a simulation model be assigned in a \lstinline!when!-clause, either by an assignment or an equation.
-The variable assigned in a \lstinline!when!-clause shall not be defined in a sub-component of \lstinline!model! or \lstinline!block! specialized class.
-(This is to keep the property of balanced models.)
-
-A \lstinline!Real! variable assigned in a \lstinline!when!-clause is a discrete-time variable,
-even though it was not declared with the prefix \lstinline!discrete!. A \lstinline!Real!
-variable not assigned in any \lstinline!when!-clause and without any type prefix is
-a continuous-time variable.
-
-The default variability for \lstinline!Integer!, \lstinline!String!,
-\lstinline!Boolean!, or \lstinline!enumeration!
-variables is discrete-time, and it is not possible to declare
-continuous-time \lstinline!Integer!, \lstinline!String!, \lstinline!Boolean!, or
-\lstinline!enumeration! variables.
-
-\begin{nonnormative}
-The restriction that discrete-valued variables (of type \lstinline!Boolean!, etc) cannot be
-declared with continuous-time variability is one of the foundations of the expression variability rules
-that will ensure that any discrete-valued expression has at most discrete-time variability, see \cref{variability-of-expressions}.
-\end{nonnormative}
+The term \firstuse[---]{parameter variable} or just \firstuse[---]{parameter} refers to a variable that is either an evaluable or non-evaluable parameter variable.
 
-The variability of expressions and restrictions on variability for
-definition equations is given in \cref{variability-of-expressions}.
+The variability of expressions and restrictions on variability for declaration equations is given in \cref{variability-of-expressions}.
 
 \begin{nonnormative}
 Note that discrete-time \emph{expressions} include parameter expressions, whereas discrete-time \emph{variables} do not include parameter variables.
-The reason can intuitively be explained as follows
+The reason can intuitively be explained as follows:
 \begin{itemize}
 \item When discussing variables we also want to consider them as left-hand-side variables in assignments, and thus a lower variability would be a problem.
 \item When discussing expressions we only consider them as right-hand-side expressions in those assignment, and thus a lower variability can automatically be included; and additionally we have sub-expressions where lower variability is not an issue.
@@ -453,7 +513,7 @@ \subsection{Component Variability Prefixes}\label{component-variability-prefixes
   parameter Boolean state = true;
   $\ldots$
 equation
-  J*a = t1 - t2;
+  J * a = t1 - t2;
   if state then // code which is removed during symbolic
     der(v) = a; // processing, if state=false
     der(r) = v;
@@ -461,17 +521,14 @@ \subsection{Component Variability Prefixes}\label{component-variability-prefixes
 end Inertia;
 \end{lstlisting}
 
-A constant variable is similar to a parameter with the difference
-that constants cannot be changed after translation and usually not
-changed after they have been given a value. It can be used to represent
-mathematical constants, e.g.
+A constant variable is similar to a parameter with the difference that constants cannot be changed after translation and usually not changed after they have been given a value.
+It can be used to represent mathematical constants, e.g.:
 \begin{lstlisting}[language=modelica]
-final constant Real PI = 4*atan(1);
+final constant Real PI = 4 * atan(1);
 \end{lstlisting}
 
-There are no continuous-time \lstinline!Boolean!, \lstinline!Integer! or \lstinline!String!
-variables. In the rare cases they are needed they can be
-faked by using \lstinline!Real! variables, e.g.:
+There are no continuous-time \lstinline!Boolean!, \lstinline!Integer! or \lstinline!String! variables.
+In the rare cases they are needed they can be faked by using \lstinline!Real! variables, e.g.:
 \begin{lstlisting}[language=modelica]
   Boolean off1, off1a;
   Real off2;
@@ -483,81 +540,129 @@ \subsection{Component Variability Prefixes}\label{component-variability-prefixes
   u2 = if noEvent(off2 > 0.5) then s2 else 0; // no state events
 \end{lstlisting}
 
-Since \lstinline!off1! is a discrete-time variable, state events are
-generated such that \lstinline!off1! is only changed at event instants.
+Since \lstinline!off1! is a discrete-time variable, state events are generated such that \lstinline!off1! is only changed at event instants.
 Variable \lstinline!off2! may change its value during continuous integration.
-Therefore, \lstinline!u1! is guaranteed to be continuous during continuous
-integration whereas no such guarantee exists for \lstinline!u2!.
+Therefore, \lstinline!u1! is guaranteed to be continuous during continuous integration whereas no such guarantee exists for \lstinline!u2!.
 \end{nonnormative}
 
-\subsubsection{Variability of Structured Entities}\label{variability-of-structured-entities}
 
-For elements of structured entities with variability prefixes the most
-restrictive of the variability prefix and the variability of the
-component wins (using the default variability for the component if there
-is no variability prefix on the component).
+\subsection{Constants}\label{constants}
 
-\begin{example}
-\begin{lstlisting}[language=modelica]
-record A
-  constant Real pi=3.14;
-  Real y;
-  Integer i;
-end A;
+Constant variables (defined in \cref{component-variability}) shall have an associated declaration equation with a constant expression, if the constant is directly in the simulation model, or used in the simulation model.
+The value of a constant can be modified after it has been given a value, unless the constant is declared \lstinline!final! or modified with a \lstinline!final! modifier.
+A constant without an associated declaration equation can be given one by using a modifier.
 
-parameter A a;
-  // a.pi is a constant
-  // a.y and a.i are parameters
+By the acyclic binding rule in \cref{acyclic-bindings-of-constants-and-parameters}, it follows that the value of a constant (or evaluable parameter, see below) to be used in simplifications is possible to obtain by evaluation of an evaluable expression where values are available for all component subexpressions.
 
-A b;
-  // b.pi is a constant
-  // b.y is a continuous-time variable
-  // b.i is a discrete-time variable
-\end{lstlisting}
-\end{example}
 
-\subsection{Conditional Component Declaration}\label{conditional-component-declaration}
+\subsection{Parameters}\label{parameters}
 
-A component declaration can have a \lstinline!condition-attribute!: \lstinline!if!~\emph{expression}.
+Parameter variables are divided into evaluable parameter variables and non-evaluable parameter variables, both defined in \cref{component-variability}.
+
+By the acyclic binding rule in \cref{acyclic-bindings-of-constants-and-parameters}, it follows that a value for an evaluable parameter is possible to obtain during translation, compare \cref{constants}.
+Making use of that value during translation turns the evaluable parameter into an evaluated parameter, and it must be ensured that the parameter cannot be assigned a different value after translation, as this would invalidate the use of the original value during translation.
 
 \begin{example}
+A particularly demanding aspect of this evaluation is the potential presence of external functions.
+Hence, if it is known that a parameter won't be used by an evaluable expression, a user can make it clear that the external function is not meant to be evaluated during translation by using \lstinline!Evaluate = false!:
 \begin{lstlisting}[language=modelica]
-  parameter Integer level(min=1)=1;
-  Motor motor;
-  Level1 component1(J=J) if level==1 "Conditional component";
-  Level2 component2 if level==2 "Conditional component";
-  Level3 component3(J=component1.J) if level<2 "Conditional component";
-  // Illegal modifier on component3 since component1.J is conditional
-  // Even if we can see that component1 always exist if component3 exist
-equation
-  connect(component1$\ldots$, $\ldots$) "Connection to conditional component 1";
-  connect(component2.n, motor.n) "Connection to conditional component 2";
-  connect(component3.n, motor.n) "Connection to conditional component 3";
-  component1.u=0; // Illegal
+import length = Modelica.Utilities.Strings.length; // Pure external function
+parameter Integer n = length("Hello");             // Evaluable parameter
+parameter Integer p = length("Hello")
+  annotation(Evaluate = false);                    // Non-evaluable parameter
+parameter Boolean b = false;                       // Evaluable parameter
+
+/* Fulfillment of acyclic binding rule might cause evaluation of n;
+ * to break the cycle, a tool might evaluate either b, n, or both:
+ */
+parameter Real x = if b and n < 3 then 1 - x else 0;
+
+/* Fulfillment of acyclic binding rule cannot cause evaluation of p;
+ * to break the cycle, evaluation of b is the only option:
+ */
+parameter Real y = if b and p < 3 then 1 - y else 0;
 \end{lstlisting}
 \end{example}
 
-The \emph{expression} must be a \lstinline!Boolean! scalar expression, and must be a parameter expression.
+\begin{nonnormative}
+For a parameter in a valid model, presence of \lstinline!Evaluate! (\cref{modelica:Evaluate}) makes it possible to tell immediately whether it is an evaluable or non-evaluable parameter, at least as long as the warning described in \cref{modelica:Evaluate} isn't triggered.
+To see this, note that \lstinline!Evaluate = false! makes it a non-evaluable parameter by definition, and that \lstinline!Evaluate = true! would trigger the warning if the parameter is non-evaluable.
+\end{nonnormative}
 
 \begin{nonnormative}
-A parameter expression is required since it shall be evaluated at compile time.
+With every non-evaluable parameter, there is at least one reason why it isn't an evaluable parameter.
+This information is useful to maintain in tools, as it allows generation of informative error messages when a violation of evaluable expression variability is detected.
+For example:
+\begin{lstlisting}[language=modelica]
+  parameter Integer n =
+    if b then 1 else 2;    // Non-evaluable parameter due to variability of b.
+  parameter Boolean b(fixed = false);
+                           // Non-evaluable parameter due to fixed = false.
+  Real[n] x;               // Variability error: n must be evaluable.
+initial equation
+  b = n > 3;
+\end{lstlisting}
+Here, a good error message for the variability error can include the information that the reason for \lstinline!n! being a non-evaluable parameter is that it has a dependency on the non-evaluable parameter \lstinline!b!.
 \end{nonnormative}
 
-A redeclaration of a component shall not include a condition attribute;
-and the condition attribute is kept from the original declaration (see
-\cref{interface-compatibility-or-subtyping}).
+\begin{nonnormative}
+Related to evaluable parameters, the term \firstuse{structural parameter} is also used in the Modelica community.
+This term has no meaning defined by the specification, and the meaning may vary from one context to another.
+One common meaning, however, is that in the context of a given tool, a parameter is called \emph{structural} if the tool has decided to evaluate it because it controls some variation of the equation structure that the tool is unable to leave undecided during translation.
+With this interpretation of \emph{structural parameter}, it follows that such a structural parameter must also be an evaluable parameter, while there are typically many evaluable parameters that are not structural.
+\end{nonnormative}
 
-If the \lstinline!Boolean! expression is false the component (including its modifier) is removed from the flattened DAE, and connections to/from the component are removed.
-A component declared with a condition-attribute can only be modified and/or used in connections.
 
-\begin{nonnormative}
-Adding the component and then removing it ensures that the component is valid.
+\subsection{Discrete-Time Variables}\label{discrete-time-variables}
 
-If a connect equation defines the connection of a non-conditional component \lstinline!c1! with a conditional component \lstinline!c2! and \lstinline!c2! is de-activated, then \lstinline!c1! must still be a declared element.
+A discrete-time variable (defined in \cref{component-variability}) has a vanishing time derivative between events.
+Note that this is not the same as saying that \lstinline!der(vd) = 0! almost everywhere, as the derivative is not even defined at the events.
+It is not allowed to apply \lstinline!der! to discrete-time variables.
 
-There are annotations to handle the case where the connector should be connected when activated, see \cref{annotations-for-the-graphical-user-interface}.
+If a \lstinline!Real! variable is declared with the prefix \lstinline!discrete!\indexinline{discrete} it must in a simulation model be assigned in a \lstinline!when!-clause, either by an assignment or an equation.
+The variable assigned in a \lstinline!when!-clause shall not be defined in a sub-component of \lstinline!model! or \lstinline!block! specialized class.
+(This is to keep the property of balanced models.)
+
+A \lstinline!Real! variable assigned in a \lstinline!when!-clause is a discrete-time variable, even though it was not declared with the prefix \lstinline!discrete!. A \lstinline!Real! variable not assigned in any \lstinline!when!-clause and without any type prefix is a continuous-time variable.
+
+The default variability for \lstinline!Integer!, \lstinline!String!, \lstinline!Boolean!, or \lstinline!enumeration! variables is discrete-time, and it is not possible to declare continuous-time \lstinline!Integer!, \lstinline!String!, \lstinline!Boolean!, or \lstinline!enumeration! variables.
+
+\begin{nonnormative}
+The restriction that discrete-valued variables (of type \lstinline!Boolean!, etc) cannot be declared with continuous-time variability is one of the foundations of the expression variability rules that will ensure that any discrete-valued expression has at most discrete-time variability, see \cref{variability-of-expressions}.
 \end{nonnormative}
 
+
+\subsection{Continuous-Time Variables}\label{continuous-time-variables}
+
+A continuous-time variable (defined in \cref{component-variability}) \lstinline!vn! may have a non-vanishing time derivative (provided \lstinline!der(vn)! is allowed this can be expressed as \lstinline!der(vn) <> 0!) and may also change its value discontinuously at any time during transient analysis (see \cref{events-and-synchronization}).
+It may also contain a combination of these effects.
+Regarding existence of \lstinline!der(vn)!, see \cref{modelica:der}.
+
+
+\subsection{Variability of Structured Entities}\label{variability-of-structured-entities}
+
+For elements of structured entities with variability prefixes the most restrictive of the variability prefix and the variability of the component wins (using the default variability for the component if there is no variability prefix on the component).
+
+\begin{example}
+\begin{lstlisting}[language=modelica]
+record A
+  constant Real pi = 3.14;
+  Real y;
+  Integer i;
+end A;
+
+parameter A a;
+  // a.pi is a constant
+  // a.y and a.i are parameters
+
+A b;
+  // b.pi is a constant
+  // b.y is a continuous-time variable
+  // b.i is a discrete-time variable
+\end{lstlisting}
+\end{example}
+
+
 \section{Class Declarations}\label{class-declarations}
 
 Essentially everything in Modelica is a \firstuse{class}, from the predefined classes \lstinline!Integer! and \lstinline!Real!, to large packages such as the Modelica standard library.
@@ -644,20 +749,18 @@ \subsection{Short Class Definitions}\label{short-class-definitions}
 
 A class definition of the form
 \begin{lstlisting}[language=modelica]
-class IDENT1 = IDENT2 class-modification;
+class IDENT1 = type-specifier class-modification;
 \end{lstlisting}
-
-is identical, except that IDENT2 may be replaceable and for the lexical
+is identical, except that \lstinline!type-specifier! (the base-class) may be replaceable and for the lexical
 scope of modifiers, where the short class definition does not introduce
 an additional lexical scope for modifiers, to the longer form
-
 \begin{lstlisting}[language=modelica]
 class IDENT1
-  extends IDENT2 class-modification;
+  extends type-specifier class-modification;
 end IDENT1;
 \end{lstlisting}
 
-An exception to the above is that if the short class definition is declared as \lstinline!encapsulated!, then the modifiers follow the rules for encapsulated classes and cannot be looked up in the enclosing scope.
+An exception to the above is that if the short class definition is declared as \lstinline!encapsulated!, then the type-specifier and modifiers follow the rules for encapsulated classes and cannot be looked up in the enclosing scope.
 
 \begin{example}
 Demonstrating the difference in scopes:
@@ -682,6 +785,7 @@ \subsection{Short Class Definitions}\label{short-class-definitions}
   $\ldots$
 end A;
 \end{lstlisting}
+The type-specifiers \lstinline!.Resistor! rely on global name lookup (see \ref{composite-name-lookup}), due to the encapsulated restriction.
 \end{example}
 
 A short class definition of the form
@@ -741,7 +845,15 @@ \subsection{Short Class Definitions}\label{short-class-definitions}
 
 \subsection{Combining Base Classes and Other Elements}\label{restriction-on-combining-base-classes-and-other-elements}\label{combining-base-classes-and-other-elements}
 
-It is not legal to combine equations, algorithms, components, base classes, or protected elements with an extends from an array class, a class with non-empty \lstinline[language=grammar]!base-prefix!, a \firstuse{simple type} (\lstinline!Real!, \lstinline!Boolean!, \lstinline!Integer!, \lstinline!String! and enumeration types), or any class transitively extending from an array class, a class with non-empty \lstinline[language=grammar]!base-prefix!, or a simple type.
+It is not legal to combine equations, algorithms, components, non-empty base classes (see below), or protected elements with an extends from an array class, a class with non-empty \lstinline[language=grammar]!base-prefix!, a \firstuse{simple type} (\lstinline!Real!, \lstinline!Boolean!, \lstinline!Integer!, \lstinline!String! and enumeration types), or any class transitively extending from an array class, a class with non-empty \lstinline[language=grammar]!base-prefix!, or a simple type.
+
+\begin{definition}[Empty class]\index{empty-class}
+A class without equations, algorithms, or components, and where any base-classes are themselves empty.
+\end{definition}
+
+\begin{nonnormative}
+An empty class may contain annotations, such as graphics, and can be used more freely as base-class than other classes.
+\end{nonnormative}
 
 \begin{example}
 \begin{lstlisting}[language=modelica]
@@ -810,7 +922,7 @@ \section{Specialized Classes}\label{specialized-classes}
 The normal modeling class in Modelica.
 
 \item \lstinline!block!\indexinline{block} --
-Same as \lstinline!model! with the restriction that each connector component of a \lstinline!block! must have prefixes \lstinline!input! and/or \lstinline!output! for all connector variables.
+Same as \lstinline!model! with the restriction that each public connector component of a \lstinline!block! must have prefixes \lstinline!input! and/or \lstinline!output! for all connector variables.
 
 \begin{nonnormative}
 The purpose is to model input/output blocks of block diagrams.  Due to the restrictions on \lstinline!input! and \lstinline!output! prefixes,
@@ -926,7 +1038,7 @@ \section{Balanced Models}\label{balanced-models}
 redeclaration cannot lead to an unbalanced model any more.
 \end{nonnormative}
 
-The restrictions below apply after flattening -- i.e.\ inherited components are included -- possibly modified.  The corresponding restrictions on connectors and connections are in
+The restrictions below apply after flattening -- i.e., inherited components are included -- possibly modified.  The corresponding restrictions on connectors and connections are in
 \cref{restrictions-of-connections-and-connectors}.
 
 \begin{definition}[Local number of unknowns]\index{local number of unknowns}
@@ -957,7 +1069,7 @@ \section{Balanced Models}\label{balanced-models}
 The local equation size of a \lstinline!model! or \lstinline!block! class is the sum of the following numbers:
 \begin{itemize}
 \item
-  The number of equations defined locally (i.e.\ not in any \lstinline!model! or \lstinline!block! component), including binding equations, and equations generated from \lstinline!connect!-equations.
+  The number of equations defined locally (i.e., not in any \lstinline!model! or \lstinline!block! component), including binding equations, and equations generated from \lstinline!connect!-equations.
   \begin{nonnormative}
   This includes the proper count for \lstinline!when!-clauses (see \cref{when-equations}), and algorithms (see \cref{algorithm-sections}), and is also used for
   the flat Hybrid DAE formulation (see \cref{modelica-dae-representation}).
@@ -965,7 +1077,7 @@ \section{Balanced Models}\label{balanced-models}
 \item
   The number of input and flow variables present in each (top-level) public connector component.
   \begin{nonnormative}
-  This represents the number of connection equations that will be provided when the class is used.
+  This represents the number of connection equations that will be provided when the class is used, due to the balancing restrictions for connectors, see \cref{balancing-restriction-and-size-of-connectors}.
   \end{nonnormative}
 \item
   The number of (top-level) public input variables that neither are connectors nor have binding equations.
@@ -1006,7 +1118,7 @@ \section{Balanced Models}\label{balanced-models}
 \begin{definition}[Globally balanced]\index{globally balanced}\index{balanced!globally}
 Similarly as locally balanced, but including all unknowns and equations
 from all components. The global number of unknowns is computed by
-expanding all unknowns (i.e.\ excluding parameters and constants) into a
+expanding all unknowns (i.e., excluding parameters and constants) into a
 set of scalars of primitive types. This should match the global equation
 size defined as:
 \begin{itemize}
@@ -1027,7 +1139,7 @@ \section{Balanced Models}\label{balanced-models}
 \item
   In a non-partial \lstinline!model! or \lstinline!block!, all non-connector inputs of \lstinline!model! or \lstinline!block! components must have binding equations.
   \begin{nonnormative}
-  E.g.\ if the model contains a component, \lstinline!firstOrder! (of specialized class \lstinline!model!) and \lstinline!firstOrder! has
+  E.g., if the model contains a component, \lstinline!firstOrder! (of specialized class \lstinline!model!) and \lstinline!firstOrder! has
   \lstinline!input Real u! then there must be a binding equation for \lstinline!firstOrder.u!.
   Note that this also applies to components inherited from a partial base-class provided the current class is non-partial.
   \end{nonnormative}
@@ -1097,7 +1209,7 @@ \section{Balanced Models}\label{balanced-models}
 \end{align*}
 and 2 equations corresponding to the 2 flow variables \lstinline!p.i! and \lstinline!n.i!.
 
-These are 5 equations in 5 unknowns (locally balanced model).  A more detailed analysis would reveal that this is structurally non-singular, i.e.\ that
+These are 5 equations in 5 unknowns (locally balanced model).  A more detailed analysis would reveal that this is structurally non-singular, i.e., that
 the hybrid DAE will not contain a singularity independent of actual values.
 
 If the equation \lstinline!u = p.v - n.v! would be missing in the \lstinline!Capacitor! model, there would be 4 equations in 5 unknowns and the model
@@ -1189,10 +1301,10 @@ \section{Balanced Models}\label{balanced-models}
 end BaseProperties;
 \end{lstlisting}
 
-The use of connector here is a special design pattern.
+The model \lstinline!BaseProperties! together with its use in derived classes and as component relies on a special design pattern defined below.
 The variables \lstinline!p!, \lstinline!h!, \lstinline!Xi! are marked as input to get correct equation count.
 Since they are connectors they should neither be given binding equations in derived classes nor when using the model.
-The design pattern is to give textual equations for them (as below); using \lstinline!connect!-equations for these connectors would be possible (and would work) but is not part of the design.
+The design pattern, which is used in this case, is to give textual equations for them (as below); using \lstinline!connect!-equations for these connectors would be possible (and would work) but is not part of the design pattern.
 
 This partial model defines that \lstinline!T!, \lstinline!d!, \lstinline!u! can be computed from
 the medium model, provided \lstinline!p!, \lstinline!h!, \lstinline!Xi! are given.  Every medium with
@@ -1390,14 +1502,14 @@ \section{Predefined Types and Classes}\label{predefined-types-and-classes}
 
 It is not possible to combine extends from the predefined types, enumeration types, or this \lstinline!Clock! type with other components.
 
-The names \lstinline!Real!\index{Real@\robustinline{Real}!reserved name}, \lstinline!Integer!\index{Integer@\robustinline{Integer}!reserved name}, \lstinline!Boolean!\index{Boolean@\robustinline{Boolean}!reserved name} and \lstinline!String!\index{String@\robustinline{String}!reserved name} are reserved such that it is illegal to declare an element with these names.
+The names \lstinline!Real!\index{Real@\robustinline{Real}!reserved name}, \lstinline!Integer!\index{Integer@\robustinline{Integer}!reserved name}, \lstinline!Boolean!\index{Boolean@\robustinline{Boolean}!reserved name} and \lstinline!String!\index{String@\robustinline{String}!reserved name} have restrictions similar to keywords, see \cref{modelica-keywords}.
 
 \begin{nonnormative}
 Hence, it is possible to define a normal class called \lstinline!Clock! in a package and extend from it.
 \end{nonnormative}
 
 \begin{nonnormative}
-It also follows that the only way to declare a subtype of e.g.\ \lstinline!Real! is to use the \lstinline!extends! mechanism.
+It also follows that the only way to declare a subtype of, e.g., \lstinline!Real! is to use the \lstinline!extends! mechanism.
 \end{nonnormative}
 
 The definitions use \lstinline!RealType!\indexinline{RealType}, \lstinline!IntegerType!\indexinline{IntegerType}, \lstinline!BooleanType!\indexinline{BooleanType}, \lstinline!StringType!\indexinline{StringType}, \lstinline!EnumType!\indexinline{EnumType} as mnemonics corresponding to machine representations.
@@ -1440,6 +1552,11 @@ \subsection{Real Type}\label{real-type}
 \index{unbounded@\robustinline{unbounded}!attribute of \robustinline{Real}}%
 \index{stateSelect@\robustinline{stateSelect}!attribute of \robustinline{Real}}
 
+The \lstinline!unit! and \lstinline!displayUnit! attributes may be either the empty string or a string matching \lstinline[language=grammar]!unit-expression! in \cref{unit-expressions}.
+The meaning of the empty string depends on the context.
+For the input and output components of a function, the empty string allows different units to be used in different calls to the function.
+For a non-function component, the empty string allows the unit (or display unit) to be inferred by the tool.
+
 The \lstinline!nominal! attribute is meant to be used for scaling purposes and to
 define tolerances in relative terms, see \cref{attributes-start-fixed-nominal-and-unbounded}.
 
@@ -1696,7 +1813,7 @@ \subsection{Attributes start, fixed, nominal, and unbounded}\label{attributes-st
 
 The attributes \lstinline!start! and \lstinline!fixed! define the initial conditions for a variable.  \lstinline!fixed = false! means an initial guess, i.e., value may be changed by static analyzer.  \lstinline!fixed = true! means a required value.  The resulting consistent set of values for \emph{all} model variables is used as initial values for the analysis to be performed.
 
-The attribute \lstinline!nominal! gives the nominal value for the variable.  The user need not set it even though the standard does not define a default value.  The lack of default allows the tool to propagate the nominal attribute based on equations, and if there is no value to propagate the tool should use a non-zero value, it may use additional information (e.g.\ \lstinline!min! attribute) to find a suitable value, and as last resort use 1.  If \lstinline!unbounded = true! it indicates that the state may grow without bound, and the error in absolute terms shall be controlled.
+The attribute \lstinline!nominal! gives the nominal value for the variable.  The user need not set it even though the standard does not define a default value.  The lack of default allows the tool to propagate the nominal attribute based on equations, and if there is no value to propagate the tool should use a non-zero value, it may use additional information (e.g., \lstinline!min! attribute) to find a suitable value, and as last resort use 1.  If \lstinline!unbounded = true! it indicates that the state may grow without bound, and the error in absolute terms shall be controlled.
 
 \begin{nonnormative}
 The nominal value can be used by an analysis tool to determine appropriate tolerances or epsilons, or may be used for scaling.  For example, the tolerance for an integrator could be computed as \lstinline!tol * (abs(nominal) + (if x.unbounded then 0 else abs(x)))!.  A default value is not provided in order that in cases such as \lstinline!a = b!, where \lstinline!b! has a nominal value but not \lstinline!a!, the nominal value can be propagated to the other variable).
diff --git a/chapters/connectors.tex b/chapters/connectors.tex
index d3d259857..830847969 100644
--- a/chapters/connectors.tex
+++ b/chapters/connectors.tex
@@ -107,15 +107,20 @@ \subsection{Expandable Connectors}\label{expandable-connectors}
 This applies to both variables of simple types, and variables of structured types.
 
 Then connections containing expandable connectors are elaborated:
-\begin{itemize}
+\begin{enumerate}
+\item
+  If a connect-equation references a potentially present component \emph{as part of the argument} it will be marked as being present, which will allow a connection to an undeclared connector inside it.
+  The rule does not apply for the complete argument.
 \item
-  One connector in the \lstinline!connect!-equation must reference a declared component, and if the other connector is an undeclared element in a declared expandable connector it is handled as follows (elements that are only potentially present are not seen as declared):
+  After that at least one connector in the connect equation must reference a declared component.
+\item
+  If the other connector is undeclared it must be in a declared component and is handled as follows:
   \begin{itemize}
   \item
     The expandable connector instance is automatically augmented with a new component having the used name and corresponding type.
   \item
     If the undeclared component is subscripted, an array variable is created, and a connection to the specific array element is performed.
-    Introducing elements in an array gives an array with at least the specified elements, other elements are either not created or have a default value (i.e.\ as if they were only potentially present, and the same note regarding the use of \lstinline!size! also applies here).
+    Introducing elements in an array gives an array with at least the specified elements, other elements are either not created or have a default value (i.e., as if they were only potentially present, and the same note regarding the use of \lstinline!size! also applies here).
   \item
     If the variable on the other side of the \lstinline!connect!-equation is \lstinline!input! or \lstinline!output! the new component will be either \lstinline!input! or \lstinline!output! to satisfy the restrictions in \cref{restrictions-of-connections-and-connectors} for a non-expandable connector.
     \begin{nonnormative}
@@ -124,12 +129,15 @@ \subsection{Expandable Connectors}\label{expandable-connectors}
     \end{nonnormative}
     For an array the \lstinline!input!/\lstinline!output! property can be deduced separately for each array element.
   \end{itemize}
+\end{enumerate}
 
+Additionally:
+\begin{itemize}
 \item
   When two expandable connectors are connected, each is augmented with the variables that are only declared in the other expandable connector (the new variables are neither \lstinline!input! nor \lstinline!output!).
   This is repeated until all connected expandable connector instances have matching variables.
   \begin{nonnormative}
-  I.e.\ each of the connector instances is expanded to be the union of all connector variables.
+  I.e., each of the connector instances is expanded to be the union of all connector variables.
   \end{nonnormative}
 
 \item
@@ -186,7 +194,7 @@ \subsection{Expandable Connectors}\label{expandable-connectors}
 \item
   All components in an expandable connector are seen as connector instances even if they are not declared as such.
   \begin{nonnormative}
-  I.e.\ it is possible to connect to e.g.\ a \lstinline!Real! variable.
+  I.e., it is possible to connect to, e.g., a \lstinline!Real! variable.
   \end{nonnormative}
 \begin{example}
 \begin{lstlisting}[language=modelica]
@@ -289,7 +297,7 @@ \subsection{Expandable Connectors}\label{expandable-connectors}
 This elaboration implies that expandable connectors can be connected even if they do not contain the same components.
 
 \begin{nonnormative}
-A tool may remove undefined variables in an expandable connector, or set them to the default value, e.g.\ zero for \lstinline!Real! variables.
+A tool may remove undefined variables in an expandable connector, or set them to the default value, e.g., zero for \lstinline!Real! variables.
 \end{nonnormative}
 
 \begin{nonnormative}
@@ -309,7 +317,7 @@ \subsection{Expandable Connectors}\label{expandable-connectors}
 \end{nonnormative}
 
 \begin{example}
-Engine system with sensors, controllers, actuator and plant that exchange information via a bus (i.e.\ via expandable connectors):
+Engine system with sensors, controllers, actuator and plant that exchange information via a bus (i.e., via expandable connectors):
 \begin{lstlisting}[language=modelica]
 import Modelica.Units.SI;
 import Modelica.Blocks.Interfaces.RealInput;
@@ -378,7 +386,7 @@ \section{Generation of Connection Equations}\label{generation-of-connection-equa
 \end{lstlisting}
 the primitive components of \lstinline!a! and \lstinline!b! form a connection set, together with an indication of whether they are from an inside or an outside connector.
 \begin{definition}[Primitive elements]\label{primitive-elements}\index{primitive element}\index{element!primitive}
-The primitive elements are of simple types or of types defined as \lstinline!operator record! (i.e.\ a component of an \lstinline!operator record! type is not split into sub-components).
+The primitive elements are of simple types or of types defined as \lstinline!operator record! (i.e., a component of an \lstinline!operator record! type is not split into sub-components).
 \end{definition}
 The elements of the connection sets are tuples of primitive variables together with an indication of inside or outside; if the same tuple belongs to two connection sets those two sets are merged, until every tuple is only present in one set.
 Composite connector types are broken down into primitive components.
@@ -416,7 +424,7 @@ \section{Generation of Connection Equations}\label{generation-of-connection-equa
   $z_{1} + z_{2} + (-z_{3}) + \ldots + z_{n} = \mathbf{0}$ (flow variables)
 \end{itemize}
 
-The bold-face $\mathbf{0}$ represents an array or scalar zero of appropriate dimensions (i.e.\ the same size as $z$).
+The bold-face $\mathbf{0}$ represents an array or scalar zero of appropriate dimensions (i.e., the same size as $z$).
 
 For an \lstinline!operator record! type this uses the operator \lstinline!'0'! -- which must be defined in the operator record -- and all of the flow variables for the \lstinline!operator record!
 must be of the same \lstinline!operator record! type.
@@ -585,7 +593,7 @@ \section{Restrictions of Connections and Connectors}\label{restrictions-of-conne
 I.e., a connection set must -- unless the model or block is partial -- contain one source of a signal (\cref{enum:exc-conn-case} covers the case where a connector of a component is left unconnected and the source given textually).
 \end{nonnormative}
 \item
-  Variables from a protected outside connector must be part of a connection set containing at least one inside connector or one declared public outside connector (i.e.\ it shall not be an implicitly defined part of an expandable connector).
+  Variables from a protected outside connector must be part of a connection set containing at least one inside connector or one declared public outside connector (i.e., it shall not be an implicitly defined part of an expandable connector).
   \begin{nonnormative}
   Otherwise it would not be possible to deduce the causality for the expandable connector element.
   \end{nonnormative}
@@ -608,12 +616,17 @@ \section{Restrictions of Connections and Connectors}\label{restrictions-of-conne
 
 \subsection{Balancing Restriction and Size of Connectors}\label{balancing-restriction-and-size-of-connectors}
 
-For each non-partial non-expandable connector class the number of flow variables shall be equal to the number of variables that are neither \lstinline!parameter!, \lstinline!constant!, \lstinline!input!, \lstinline!output!, \lstinline!stream! nor \lstinline!flow!.
+For each non-partial non-simple non-expandable connector class the number of flow variables shall be equal to the number of variables that are neither \lstinline!parameter!, \lstinline!constant!, \lstinline!input!, \lstinline!output!, \lstinline!stream! nor \lstinline!flow!.
 The \emph{number of variables} is the number of all elements in the connector class after expanding all records and arrays to a set of scalars of primitive types.
 The number of variables of an overdetermined type or record class (see \cref{overconstrained-equation-operators-for-connection-graphs}) is the size of the output argument of the corresponding \lstinline!equalityConstraint!() function.
+A simple connector class is not expandable, has some time-varying variables, and has neither \lstinline!input!, \lstinline!output!, \lstinline!stream! nor \lstinline!flow! variables.
 \begin{nonnormative}
 Expandable connector classes are excluded from this, since their component declarations are only a form of constraint.
 \end{nonnormative}
+A component of a simple connector class must be declared as \lstinline!input!, \lstinline!output!, or \lstinline!protected!.
+\begin{nonnormative}
+A simple connector class is thus always unbalanced, but since it is used with causality or not visible to the outside it does not unbalance the model.
+\end{nonnormative}
 
 \begin{example}
 \begin{lstlisting}[language=modelica]
@@ -974,9 +987,11 @@ \subsubsection{A Power Systems Overdetermined Connector}\label{an-overdetermined
   AC_Plug p;
 equation
   Connections.root(p.theta);
-  der(p.theta) = 2*Modelica.Constants.pi*50 // 50 Hz;
+  p.theta = 2*Modelica.Constants.pi*50*time; // 50 Hz
 \end{lstlisting}
 The graph analysis performed with the virtual connection graph identifies the connectors, where the \lstinline!AC_Angle! needs not to be passed between components, in order to avoid redundant equations.
+
+Note that the different sources do not integrate the frequency, as that increases the risk of numerical errors.
 \end{nonnormative}
 
 \subsubsection{A 3-Dimensional Mechanical Systems Overdetermined Connector}\label{an-overdetermined-connector-for-3-dimensional-mechanical-systems}\label{a-3-dimensional-mechanical-systems-overdetermined-connector}
diff --git a/chapters/copyright.tex b/chapters/copyright.tex
index b88560929..a64d4a28c 100644
--- a/chapters/copyright.tex
+++ b/chapters/copyright.tex
@@ -1,4 +1,4 @@
-Copyright \textcopyright{} 1998-2021, Modelica Association (\url{https://modelica.org})
+Copyright \textcopyright{} 1998-2023, Modelica Association (\url{https://modelica.org})
 
 All rights reserved.
 Reproduction or use of editorial or pictorial content is permitted, i.e., this document can be freely distributed especially electronically, provided the copyright notice and these conditions are retained.
diff --git a/chapters/dae.tex b/chapters/dae.tex
index dd656104d..1caeb0276 100644
--- a/chapters/dae.tex
+++ b/chapters/dae.tex
@@ -74,7 +74,7 @@ \chapter{Modelica DAE Representation}\label{modelica-dae-representation}
 
 \item
   $\mathit{relation}(v)$:
-  A relation containing variables $v_{i}$, e.g.\ $v_{1} > v_{2}$, $v_{3} \geq 0$.
+  A relation containing variables $v_{i}$, e.g., $v_{1} > v_{2}$, $v_{3} \geq 0$.
 \end{itemize}
 
 For simplicity, the special cases of \lstinline!noEvent! and \lstinline!reinit! are not contained in the equations above and are not discussed below.
@@ -170,7 +170,7 @@ \chapter{Modelica DAE Representation}\label{modelica-dae-representation}
 
 Solving \eqref{eq:hydrid-dae} for the unknowns is non-trivial, because this set of equations contains not only \lstinline!Real!, but also discrete-valued unknowns.
 Usually, in a first step these equations are sorted and in many cases the discrete-valued unknowns $m$ can be just computed by a forward evaluation sequence.
-In some cases, there remain systems of equations involving $m$ due to cyclic dependencies with $y$ and $z$ (e.g.\ for ideal diodes, Coulomb friction elements), and specialized algorithms have to be used to solve them.
+In some cases, there remain systems of equations involving $m$ due to cyclic dependencies with $y$ and $z$ (e.g., for ideal diodes, Coulomb friction elements), and specialized algorithms have to be used to solve them.
 
 Due to the construction of the equations by \emph{flattening} a Modelica model, the hybrid DAE \eqref{eq:hydrid-dae} contains a huge number of sparse equations.
 Therefore, direct simulation of \eqref{eq:hydrid-dae} requires sparse matrix methods.
diff --git a/chapters/equations.tex b/chapters/equations.tex
index b695547eb..e7095c5cb 100644
--- a/chapters/equations.tex
+++ b/chapters/equations.tex
@@ -104,7 +104,7 @@ \subsubsection{Explicit Iteration Ranges of For-Equations}\label{explicit-iterat
 
 The \lstinline!expression! of a \lstinline!for!-equation shall be a vector expression, where more general array expressions are treated as vector of vectors or vector of matrices.
 It is evaluated once for each \lstinline!for!-equation, and is evaluated in the scope immediately enclosing the \lstinline!for!-equation.
-The expression of a \lstinline!for!-equation shall be a parameter expression.
+The expression of a \lstinline!for!-equation shall be evaluable.
 The iteration range of a \lstinline!for!-equation can also be specified as \lstinline!Boolean! or as an enumeration type, see \cref{types-as-iteration-ranges} for more information.
 The loop-variable (\lstinline!IDENT!) is in scope inside the loop-construct and shall not be assigned to.
 For each element of the evaluated vector expression, in the normal order, the loop-variable gets the value of that element and that is used to evaluate the body of the \lstinline!for!-loop.
@@ -204,7 +204,7 @@ \subsection{When-Equations}\label{when-equations}
 The equations within a \lstinline!when!-equation are activated only at the instant when the scalar expression or any of the elements of the vector expression becomes true.
 
 \begin{example}
-The order between the equations in a \lstinline!when!-equation does not matter, e.g.
+The order between the equations in a \lstinline!when!-equation does not matter, e.g.:
 \begin{lstlisting}[language=modelica]
 equation
   when x > 2 then
@@ -442,7 +442,7 @@ \subsection{reinit}\label{reinit}
 \end{lstlisting}
 
 The operator reinitializes \lstinline!x! with \lstinline!expr! at an event instant.
-\lstinline!x! is a \lstinline!Real! variable (or an array of \lstinline!Real! variables) that must be selected as a state (resp., states), i.e.\ \lstinline!reinit! on \lstinline!x! implies \lstinline!stateSelect = StateSelect.always! on \lstinline!x!.
+\lstinline!x! is a \lstinline!Real! variable (or an array of \lstinline!Real! variables) that must be selected as a state (resp., states), i.e., \lstinline!reinit! on \lstinline!x! implies \lstinline!stateSelect = StateSelect.always! on \lstinline!x!.
 \lstinline!expr! needs to be type-compatible with \lstinline!x!.
 For any given variable (possibly an array variable), \lstinline!reinit! can only be applied (either to an individual variable or to a part of an array variable) in one \lstinline!when!-equation (applying \lstinline!reinit! to a variable in several \lstinline!when!- or \lstinline!elsewhen!-clauses of the same \lstinline!when!-equation is allowed).
 If there are multiple \lstinline!reinit! for a variable inside the same \lstinline!when!- or \lstinline!elsewhen!-clause, they must appear in different branches of an \lstinline!if!-equation (in order that at most one \lstinline!reinit! for the variable is active at any event).
@@ -578,7 +578,7 @@ \section{Events and Synchronization}\label{events-and-synchronization}
 An \firstuse{event} is something that occurs instantaneously at a specific time or when a specific condition occurs.
 Events are for example defined by the condition occurring in a \lstinline!when!-clause, \lstinline!if!-equation, or \lstinline!if!-expression.
 
-The integration is halted and an event occurs whenever an event generation expression, e.g.\ \lstinline!x > 2! o or \lstinline!floor(x)!, changes its value.
+The integration is halted and an event occurs whenever an event generation expression, e.g., \lstinline!x > 2! o or \lstinline!floor(x)!, changes its value.
 An event generating expression has an internal buffer, and the value of the expression can only be changed at event instants.
 If the evaluated expression is inconsistent with the buffer, that will trigger an event and the buffer will be updated with a new value at the event instant.
 During continuous integration event generation expression has the constant value of the expression from the last event instant.
@@ -624,9 +624,9 @@ \section{Events and Synchronization}\label{events-and-synchronization}
 In this case \lstinline!x = y = z!, but a tool might generate events for \lstinline!z!.
 The \lstinline!if!-expression is taken literally without inducing state events.
 
-The \lstinline!smooth! operator is useful, if e.g.\ the modeler can guarantee that the used \lstinline!if!-expressions fulfill at least the continuity requirement of integrators.
+The \lstinline!smooth! operator is useful, if, e.g., the modeler can guarantee that the used \lstinline!if!-expressions fulfill at least the continuity requirement of integrators.
 In this case the simulation speed is improved, since no state event iterations occur during integration.
-The \lstinline!noEvent! operator is used to guard against \emph{outside domain} errors, e.g.\ \lstinline!y = if noEvent(x >= 0) then sqrt(x) else 0.!
+The \lstinline!noEvent! operator is used to guard against \emph{outside domain} errors, e.g., \lstinline!y = if noEvent(x >= 0) then sqrt(x) else 0.!
 \end{example}
 
 All equations and assignment statements within \lstinline!when!-clauses and all assignment statements within \lstinline!function! classes are implicitly treated with \lstinline!noEvent!, i.e., relations within the scope of these operators never induce state or time events.
@@ -650,7 +650,7 @@ \section{Events and Synchronization}\label{events-and-synchronization}
 
 \begin{nonnormative}
 The rules for the synchronous data flow principle guarantee that variables are always defined by a unique set of equations.
-It is not possible that a variable is e.g.\ defined by two equations, which would give rise to conflicts or non-deterministic behavior.
+It is not possible that a variable is, e.g., defined by two equations, which would give rise to conflicts or non-deterministic behavior.
 Furthermore, the continuous and the discrete parts of a model are always automatically ``synchronized''.
 Example:
 \begin{lstlisting}[language=modelica]
@@ -682,7 +682,7 @@ \section{Events and Synchronization}\label{events-and-synchronization}
 There is no guarantee that two different events occur at the same time instant.
 
 \begin{nonnormative}
-As a consequence, synchronization of events has to be explicitly programmed in the model, e.g.\ via counters.
+As a consequence, synchronization of events has to be explicitly programmed in the model, e.g., via counters.
 Example:
 \begin{lstlisting}[language=modelica]
   Boolean fastSample, slowSample;
@@ -745,7 +745,7 @@ \section{Initialization, initial equation, and initial algorithm}\label{initiali
 There is no special handling of inactive \lstinline!when!-statements during initialization, instead variables assigned in \lstinline!when!-statements are initialized using \lstinline!v := pre(v)! before the body of the algorithm (since they are discrete), see \cref{execution-of-an-algorithm-in-a-model}.
 \end{nonnormative}
 
-Further constraints, necessary to determine the initial values of all variables (depending on the component variability, see \cref{component-variability-prefixes-discrete-parameter-constant} for definitions), can be defined in the following ways:
+Further constraints, necessary to determine the initial values of all variables (depending on the component variability, see \cref{component-variability} for definitions), can be defined in the following ways:
 \begin{enumerate}
 \item
   As equations in an \lstinline!initial equation!\indexinline{initial equation} section or as assignments in an \lstinline!initial algorithm!\indexinline{initial algorithm} section.
@@ -770,7 +770,7 @@ \section{Initialization, initial equation, and initial algorithm}\label{initiali
   \end{itemize}
 \end{enumerate}
 
-Constants shall be determined by declaration equations (see \cref{component-variability-prefixes-discrete-parameter-constant}), and \lstinline!fixed = false! is not allowed.
+Constants shall be determined by declaration equations (see \cref{constants}), and \lstinline!fixed = false! is not allowed.
 For parameters, \lstinline!fixed! defaults to \lstinline!true!.
 For other variables, \lstinline!fixed! defaults to \lstinline!false!.
 
@@ -787,7 +787,7 @@ \section{Initialization, initial equation, and initial algorithm}\label{initiali
 This is used in libraries to give rudimentary defaults so that users can quickly combine models and simulate without setting parameters; but still easily find the parameters that should be set properly.
 \end{nonnormative}
 
-All variables declared as \lstinline!parameter! having \lstinline!fixed = false! are treated as unknowns during the initialization phase, i.e.\ there must be additional equations for them -- and the \lstinline!start!-value can be used as a guess-value during initialization.
+All variables declared as \lstinline!parameter! having \lstinline!fixed = false! are treated as unknowns during the initialization phase, i.e., there must be additional equations for them -- and the \lstinline!start!-value can be used as a guess-value during initialization.
 
 \begin{nonnormative}
 In the case a parameter has both a binding equation and \lstinline!fixed = false! a diagnostic is recommended, but the parameter should be solved from the binding equation.
@@ -808,7 +808,7 @@ \section{Initialization, initial equation, and initial algorithm}\label{initiali
 These non-normative considerations are addressed as follows.
 A tool may add or remove initial equations automatically according to the rules below such that the resulting system is structurally nonsingular:
 \begin{itemize}
-\item A missing initial value of a discrete-time variable (see \cref{component-variability-prefixes-discrete-parameter-constant} -- this does not include parameter and constant variables) which does not influence the simulation result, may be automatically set to the start value or its default without informing the user.
+\item A missing initial value of a discrete-time variable (see \cref{component-variability} -- this does not include parameter and constant variables) which does not influence the simulation result, may be automatically set to the start value or its default without informing the user.
 For example, variables assigned in a \lstinline!when!-clause which are not accessed outside of the \lstinline!when!-clause and where \lstinline!pre! is not explicitly used on these variables, do not have an effect on the simulation.
 \item A \lstinline!start!-attribute that is not fixed may be treated as fixed with a diagnostic.
 \item A consistent start value or initial equation may be removed with a diagnostic.
diff --git a/chapters/functions.tex b/chapters/functions.tex
index d50a26924..dc9ef90a3 100644
--- a/chapters/functions.tex
+++ b/chapters/functions.tex
@@ -145,7 +145,7 @@ \section{Function as a Specialized Class}\label{function-as-a-specialized-class}
 
 \begin{nonnormative}
 The syntax and semantics of a function have many similarities to those of the \lstinline!block! specialized class. A function has many of the properties
-of a general class, e.g.\ being able to inherit other functions, or to redeclare or modify elements of a function declaration.
+of a general class, e.g., being able to inherit other functions, or to redeclare or modify elements of a function declaration.
 \end{nonnormative}
 
 Modelica functions have the following restrictions compared to a general
@@ -244,7 +244,7 @@ \section{Pure Modelica Functions}\label{pure-modelica-functions}
 \item
   \emph{Pure} Modelica functions always give the same output values or
   errors for the same input values and only the output values influence
-  the simulation result, i.e.\ is seen as equivalent to a mathematical
+  the simulation result, i.e., is seen as equivalent to a mathematical
   map from input values to output values. Some input values may map to
   errors. Pure functions are thus allowed to fail by calling \lstinline!assert!, or
   \lstinline[language=C]!ModelicaError! in C code, or dividing by zero. Such errors will only be
@@ -292,7 +292,7 @@ \section{Pure Modelica Functions}\label{pure-modelica-functions}
 containing function calls while still preserving their semantics. For
 example, a tool may use common subexpression elimination to call a pure
 function just once, if it is called several times with identical input
-arguments. However, since functions may fail we can e.g.\ only move a
+arguments. However, since functions may fail we can, e.g., only move a
 common function call from inside a loop to outside the loop if the loop
 is run at least once.
 \end{nonnormative}
@@ -302,7 +302,7 @@ \section{Pure Modelica Functions}\label{pure-modelica-functions}
 maintaining this property for pure non-external functions. Regarding
 external functions, the external function implementor is responsible.
 Note that external functions can have side-effects as long as they do
-not influence the internal Modelica simulation state, e.g.\ caching
+not influence the internal Modelica simulation state, e.g., caching
 variables for performance or printing trace output to a log file.
 \end{nonnormative}
 
@@ -754,7 +754,7 @@ \subsection{Initialization and Binding Equations}%
 (before executing the algorithm section or calling the external
 function). These bindings must be executed in an order where a variable
 is not used before its binding equations has been executed; it is
-an error if no such order exists (i.e.\ the binding must be acyclic).
+an error if no such order exists (i.e., the binding must be acyclic).
 
 % The first sentence below needs clarification: clearly, binding equation can also be used for components outside functions.
 Binding equations can only be used for components of a function.
@@ -822,7 +822,7 @@ \subsection{Flexible Array Sizes and Resizing of Arrays}\label{flexible-array-si
 
 \subsection{Automatic Vectorization}\label{scalar-functions-applied-to-array-arguments}\label{automatic-vectorization}
 
-Functions with one scalar return value can be applied to arrays element-wise, e.g.\ if \lstinline!A! is a vector of reals, then \lstinline!sin(A)! is a vector where each element is the result of applying the function \lstinline!sin! to the corresponding element in \lstinline!A!.
+Functions with one scalar return value can be applied to arrays element-wise, e.g., if \lstinline!A! is a vector of reals, then \lstinline!sin(A)! is a vector where each element is the result of applying the function \lstinline!sin! to the corresponding element in \lstinline!A!.
 Only \lstinline!function! classes that are transitively non-replaceable (\cref{transitively-non-replaceable} and \cref{restrictions-on-base-classes-and-constraining-types-to-be-transitively-non-replaceable}) may be called vectorized.
 
 Consider the expression \lstinline!f(arg1, $\ldots$, argn)!, an application of the function \lstinline!f! to the arguments \lstinline!arg1!, \ldots, \lstinline!argn!.
@@ -1353,7 +1353,7 @@ \subsection{Using the Derivative Annotation}\label{using-the-derivative-annotati
   and its derivative.
 \end{itemize}
 
-If the Modelica function call is a $n$th derivative ($n \geq 1$), i.e.\ this function call has been derived from an $(n-1)$th derivative by differentiation inside the tool, an {\lstinline!annotation(derivative(order=$n+1$) = $\ldots$)!}, specifies the $(n+1)$th derivative, and the $(n+1)$th derivative call is constructed as follows:
+If the Modelica function call is a $n$th derivative ($n \geq 1$), i.e., this function call has been derived from an $(n-1)$th derivative by differentiation inside the tool, an {\lstinline!annotation(derivative(order=$n+1$) = $\ldots$)!}, specifies the $(n+1)$th derivative, and the $(n+1)$th derivative call is constructed as follows:
 \begin{itemize}
 \item
   The input arguments are appended with the $(n+1)$th derivative, which are constructed in order from the $n$th {\lstinline!order!} derivatives.
@@ -1491,7 +1491,7 @@ \subsection{Using the Derivative Annotation}\label{using-the-derivative-annotati
   {\lstinline[language=grammar]!"zeroDerivative" "=" $\mathit{inputVar}_{1}$ { "," "zeroDerivative" "=" $\mathit{inputVar}_{2}$ }!}
 \end{itemize}
 
-The derivative function is only valid if $\mathit{inputVar}_{1}$ (and $\mathit{inputVar}_{2}$ etc.) are independent of the variables the function call is differentiated with respect to (i.e.\ that the derivative of $\mathit{inputVar}_{1}$ is zero).
+The derivative function is only valid if $\mathit{inputVar}_{1}$ (and $\mathit{inputVar}_{2}$ etc.) are independent of the variables the function call is differentiated with respect to (i.e., that the derivative of $\mathit{inputVar}_{1}$ is zero).
 The derivative of $\mathit{inputVar}_{1}$ (and $\mathit{inputVar}_{2}$ etc.) are excluded from the argument list of the derivative-function.
 If the derivative-function also specifies a derivative the common variables should have consistent {\lstinline!zeroDerivative!}.
 
@@ -1631,7 +1631,8 @@ \subsection{Partial Derivatives of Functions}\label{partial-derivatives-of-funct
 \end{lstlisting}
 is the partial derivative of a function, and may only be used as declarations of functions.
 
-The semantics is that a function (and only a function) can be specified in this form, defining that it is the partial derivative of the function to the right of the equal sign (looked up in the same way as a short class definition, and the looked up name must be a function), and partially differentiated with respect to each {\lstinline!IDENT!} in order (starting from the first one).  The {\lstinline!IDENT!} must be {\lstinline!Real!} inputs to the function.
+The semantics is that a function (and only a function) can be specified in this form, defining that it is the partial derivative of the function to the right of the equal sign (looked up in the same way as a short class definition, and the looked up name must be a function), and partially differentiated with respect to each {\lstinline!IDENT!} in order (starting from the first one).
+Each {\lstinline!IDENT!} must be a scalar {\lstinline!Real!} input to the function.
 
 The comment allows a user to comment the function (in the info-layer and as one-line description, and as icon).
 
@@ -1908,7 +1909,7 @@ \section{External Function Interface}\label{external-function-interface}
 \begin{itemize}
 \item
   Support for external functions written in C (specifically C89) and
-  FORTRAN~77. Other languages, e.g.\ C++ and Fortran 90, may be supported
+  FORTRAN~77. Other languages, e.g., C++ and Fortran 90, may be supported
   in the future, and provided the function is link-compatible with C89
   or FORTRAN~77 it can be written in any language.
 \item
@@ -1954,7 +1955,7 @@ \section{External Function Interface}\label{external-function-interface}
 Unless the external language is specified, it is assumed to be {\lstinline!"C"!}.
 
 \begin{nonnormative}
-The intended use of e.g.\ C99 is to detect if the user tries to link with a C99-function using a C89 compiler.
+The intended use of, e.g., C99 is to detect if the user tries to link with a C99-function using a C89 compiler.
 \end{nonnormative}
 
 The deprecated {\lstinline!"builtin"!} specification is only used for the elementary mathematical functions described in \cref{built-in-mathematical-functions-and-external-built-in-functions}.
@@ -1997,7 +1998,7 @@ \section{External Function Interface}\label{external-function-interface}
 \subsection{Argument type Mapping}\label{argument-type-mapping}
 
 The arguments of the external function are declared in the same order as in the Modelica declaration, unless specified otherwise in an explicit external function call.
-Protected variables (i.e.\ temporaries) are passed in the same way as outputs, whereas constants and {\lstinline!size!} calls are passed as inputs.
+Protected variables (i.e., temporaries) are passed in the same way as outputs, whereas constants and {\lstinline!size!} calls are passed as inputs.
 
 \subsubsection{Simple Types}\label{simple-types}
 
@@ -2048,10 +2049,10 @@ \subsubsection{Simple Types}\label{simple-types}
                                          & \multicolumn{1}{c}{\tablehead{Input}} & \multicolumn{1}{c}{\tablehead{Output}}\\
 \hline
 \hline
-{\lstinline!}Real!} & {\lstinline[language=FORTRAN77]!DOUBLE PRECISION!} & {\lstinline[language=FORTRAN77]!DOUBLE PRECISION!}\\
-{\lstinline!}Integer!} & {\lstinline[language=FORTRAN77]!INTEGER!} & {\lstinline[language=FORTRAN77]!INTEGER!}\\
-{\lstinline!}Boolean!} & {\lstinline[language=FORTRAN77]!LOGICAL!} & {\lstinline[language=FORTRAN77]!LOGICAL!}\\
-{\lstinline!}String!} & \emph{Special} & \emph{Not available}\\
+{\lstinline!Real!} & {\lstinline[language=FORTRAN77]!DOUBLE PRECISION!} & {\lstinline[language=FORTRAN77]!DOUBLE PRECISION!}\\
+{\lstinline!Integer!} & {\lstinline[language=FORTRAN77]!INTEGER!} & {\lstinline[language=FORTRAN77]!INTEGER!}\\
+{\lstinline!Boolean!} & {\lstinline[language=FORTRAN77]!LOGICAL!} & {\lstinline[language=FORTRAN77]!LOGICAL!}\\
+{\lstinline!String!} & \emph{Special} & \emph{Not available}\\
 Enumeration type & {\lstinline[language=FORTRAN77]!INTEGER!} & {\lstinline[language=FORTRAN77]!INTEGER!}\\
 \hline
 \end{tabular}
@@ -2218,7 +2219,7 @@ \subsubsection{Records}\label{records}
   Arrays cannot be mapped.
 \end{itemize}
 
-Records are passed by reference (i.e.\ a pointer to the record is being
+Records are passed by reference (i.e., a pointer to the record is being
 passed).
 
 \begin{example}
@@ -2325,7 +2326,7 @@ \subsection{Aliasing}\label{aliasing}
 inputs is to ensure that inputs can be stored in static memory and to
 avoid superfluous copying (especially of matrices). If the routine does
 not satisfy the requirements the interface must copy the input argument
-to a temporary. This is rare but occurs e.g.\ in {\lstinline!dormlq!} in some
+to a temporary. This is rare but occurs, e.g., in {\lstinline!dormlq!} in some
 Lapack implementations. In those special cases the writer of the
 external interface have to copy the input to a temporary. If the first
 input was changed internally in myfoo the designer of the interface
@@ -2379,7 +2380,7 @@ \subsection{Annotations for External Functions}\label{annotations-for-external-l
   The
   {\lstinline!annotation(LibraryDirectory="modelica://ModelicaLibraryName/Resources/Library")!}\annotationindex{LibraryDirectory}, used to specify a location for library files.
   The preceding one is the default and need not be specified; but another location could be specified by using an URI name for the library directory, see \cref{external-resources}.
-  Different versions of one object library can be provided (e.g.\ for Windows and for Linux) by providing a \emph{platform} directory below the {\lstinline!LibraryDirectory!}.
+  Different versions of one object library can be provided (e.g., for Windows and for Linux) by providing a \emph{platform} directory below the {\lstinline!LibraryDirectory!}.
   If no platform directory is present, the object library must be present in the {\lstinline!LibraryDirectory!}.
   The following \emph{platform} names are standardized:
   \begin{itemize}
@@ -2412,7 +2413,7 @@ \subsection{Annotations for External Functions}\label{annotations-for-external-l
 
 \begin{nonnormative}
 A tool may give a diagnostic if the directory corresponding to the selected compiler version is missing.
-The directories may use symbolic links or use a text-file as described below: e.g.\ a text-file \filename{vs2008} containing the text \emph{../win32/vs2005} (or \emph{vs2005}) suggesting that it is compatible with vs2005.
+The directories may use symbolic links or use a text-file as described below: e.g., a text-file \filename{vs2008} containing the text \emph{../win32/vs2005} (or \emph{vs2005}) suggesting that it is compatible with vs2005.
 \end{nonnormative}
 
 The {\lstinline!ModelicaLibraryName!} used for {\lstinline!IncludeDirectory!}, {\lstinline!LibraryDirectory!}, and {\lstinline!SourceDirectory!} indicates the top-level class where the annotation is found in the Modelica source code.
@@ -2797,7 +2798,7 @@ \subsection{External Objects}\label{external-objects}
   Since the class is partial, it is not possible to define an instance of this class.
   \end{nonnormative}
 \item
-  An external object class shall be directly extended from {\lstinline!ExternalObject!}, shall have exactly two function definitions, called {\lstinline!constructor!} and {\lstinline!destructor!}, and shall not contain other elements.
+  An external object class shall be directly extended from {\lstinline!ExternalObject!}, shall have exactly two function definitions, called {\lstinline!constructor!} and {\lstinline!destructor!}, may extend from empty classes (\cref{empty-class}), but not contain any other elements.
   The functions {\lstinline!constructor!} and {\lstinline!destructor!} shall not be replaceable.
   It is not legal to call the {\lstinline!constructor!} and {\lstinline!destructor!} functions explicitly.
 \item
@@ -2818,13 +2819,13 @@ \subsection{External Objects}\label{external-objects}
   \end{nonnormative}
   \begin{nonnormative}
   External objects may be an input (or part of an input) to a function, in that case the destructor is not called (since the external object is active before and after the function call).
-  Normally this is an external function, but it could be a non-external function as well (e.g.\ calling external functions one or more times).
+  Normally this is an external function, but it could be a non-external function as well (e.g., calling external functions one or more times).
   The function input shall not have a default value using the constructor.
   \end{nonnormative}
 \item
   An external object class shall be of the specialized class {\lstinline!class!}.
   \begin{nonnormative}
-  This is the only use of {\lstinline!class!}.
+  Apart from empty classes (\cref{empty-class}), this is the only use of {\lstinline!class!}.
   \end{nonnormative}
 \item
   Classes derived from {\lstinline!ExternalObject!} can neither be used in an {\lstinline!extends!}-clause nor in a short class definition.
diff --git a/chapters/inheritance.tex b/chapters/inheritance.tex
index a6d35169a..12c6864e5 100644
--- a/chapters/inheritance.tex
+++ b/chapters/inheritance.tex
@@ -197,7 +197,7 @@ \subsection{Restrictions on the Kind of Base Class}\label{restrictions-on-the-ki
 own kind and from \lstinline!class!.
 
 \begin{nonnormative}
-E.g.\ a package can only be base class for packages.
+E.g., a package can only be base class for packages.
 All other kinds of classes can use the \lstinline!import!-clause to use the contents of a package.
 \end{nonnormative}
 
@@ -231,7 +231,7 @@ \subsection{Require Transitively Non-Replaceable}\label{restrictions-on-base-cla
 For a replaceable component declaration without \lstinline[language=grammar]!constraining-clause! the class must use a class reference considered transitively non-replaceable.
 
 \begin{nonnormative}
-The requirement to use a transitively non-replaceable name excludes the long form of redeclare, i.e.\ \lstinline!redeclare model extends M $\ldots$! where \lstinline!M! must be an inherited replaceable class.
+The requirement to use a transitively non-replaceable name excludes the long form of redeclare, i.e., \lstinline!redeclare model extends M $\ldots$! where \lstinline!M! must be an inherited replaceable class.
 \end{nonnormative}
 
 \begin{nonnormative}
@@ -567,13 +567,13 @@ \subsection{Final Element Modification Prevention}\label{final-element-modificat
 \end{example}
 
 \subsection{Removing Modifiers -- break}\label{removing-modifiers-break}
-Modifications may contain the special keyword \lstinline!break! instead of an expression.
+Modifications may contain the special keyword \lstinline!break!\index{break@\robustinline{break}!removing modifier} instead of an expression.
 The intention of \lstinline!break! is to remove the value.
 
 The modifiers using \lstinline!break! are merged using the same rule as other modifications, and follow the same restrictions so they cannot override a final modifier.
 During flattening of an instantiated model, remaining \lstinline!break! modifications (i.e., the ones that are not further overriden) are treated as if the expression was missing.
 The \lstinline!break! modifier for a variable of a simple type can be applied to the value and/or to specific attributes.
-It is possible to override even if no value is present, either because there was no expression originally or because \lstinline!break! overrides another \lstinline!break!.
+Unless \lstinline!final! was specified, it is possible to override even if no value is present, either because there was no expression originally or because \lstinline!break! overrides another \lstinline!break!.
 
 \begin{nonnormative}
 In a dialog, a tool may hide the keyword \lstinline!break! and show an empty input field, without the overriden modification.
@@ -612,7 +612,7 @@ \subsection{Removing Modifiers -- break}\label{removing-modifiers-break}
 end A;
 
 model B "Initial equation for diameter"
-  extends A( diameter(fixed = false) = break );
+  extends A( final diameter(fixed = false) = break );
   parameter Real square=2;
 initial equation
   //  solving equation below for diameter
@@ -626,7 +626,7 @@ \subsection{Removing Modifiers -- break}\label{removing-modifiers-break}
 end A;
 
 model B "Computing x instead"
-  extends A(x=break);
+  extends A(final x=break);
 algorithm
   x:=0;
   while ...
@@ -857,7 +857,7 @@ \subsection{The ``class extends'' Redeclaration Mechanism}\label{the-class-exten
 Here, the usual approach is used to extend (here from \lstinline!PartialMedium!) and in the modifier perform all redeclarations.
 In order to perform these redeclarations, corresponding implementations of all elements of \lstinline!PartialMedium! have to be given under a different name, such as \lstinline!MoistAir2.MoistAir_BaseProperties!, since the name \lstinline!BaseProperties! already exists due to \lstinline!extends PartialMedium!.
 Then it is possible in the modifier to redeclare \lstinline!PartialMedium.BaseProperties! to \lstinline!MoistAir2.MoistAir_BaseProperties!.
-Besides the drawback that the namespace is polluted by elements that have different names but the same implementation (e.g.\ \lstinline!MoistAir2.BaseProperties! is identical to \lstinline!MoistAir2.MoistAir_BaseProperties!) the whole construction does not work if arrays are present that depend on constants in \lstinline!PartialMedium!, such as \lstinline!X[nX]!:
+Besides the drawback that the namespace is polluted by elements that have different names but the same implementation (e.g., \lstinline!MoistAir2.BaseProperties! is identical to \lstinline!MoistAir2.MoistAir_BaseProperties!) the whole construction does not work if arrays are present that depend on constants in \lstinline!PartialMedium!, such as \lstinline!X[nX]!:
 The problem is that \lstinline!MoistAir_BaseProperties! extends from \lstinline!PartialMedium.BaseProperties! where the constant \lstinline!nX! does not yet have a value.
 This means that the dimension of array \lstinline!X! is undefined and model \lstinline!MoistAir_BaseProperties! is wrong.
 With this construction, all constant definitions have to be repeated whenever these constants shall be used, especially in \lstinline!MoistAir_BaseProperties! and \lstinline!MoistAir_dynamicViscosity!.
@@ -1001,8 +1001,8 @@ \subsection{Constraining Type}\label{constraining-type}
 replaceable T1[n] x constrainedby T2;
 \end{lstlisting}
 In these examples the number of dimensions must be the same in \lstinline!T1! and \lstinline!T2!, as well as in a redeclaration.  Normally \lstinline!T1! and \lstinline!T2! are scalar types, but both
-could also be defined as array types (with the same number of dimensions).  Thus if \lstinline!T2! is a scalar type (e.g.\ \lstinline!type T2 = Real!) then \lstinline!T1! must also be a scalar type,
-and if \lstinline!T2! is defined as vector type (e.g.\ \lstinline!type T2 = Real[3]!) then \lstinline!T1! must also be vector type.
+could also be defined as array types (with the same number of dimensions).  Thus if \lstinline!T2! is a scalar type (e.g., \lstinline!type T2 = Real!) then \lstinline!T1! must also be a scalar type,
+and if \lstinline!T2! is defined as vector type (e.g., \lstinline!type T2 = Real[3]!) then \lstinline!T1! must also be vector type.
 \end{example}
 
 \subsubsection{Constraining-Clause Annotations}\label{constraining-clause-annotations}
@@ -1060,6 +1060,12 @@ \subsection{Restrictions on Redeclarations}\label{restrictions-on-redeclarations
 \subsection{Annotations for Redeclaration and Modification}\label{annotation-choices-for-suggested-redeclarations-and-modifications}
 
 A declaration can have an annotation \fmtannotationindex{choices} containing modifiers on \lstinline!choice!, where each of them indicates a suitable redeclaration or modifications of the element.
+Lookup inside a \lstinline!choice! modifier is performed in the context of the annotation, meaning that references may need to be transformed to preserve the meaning when a \lstinline!choice! is applied in a different context.
+
+\begin{nonnormative}
+It is recommended to avoid expressions with references to elements that are not globally accessible, such as contents within a \lstinline!protected! section of a class.
+By starting names with a dot it can be ensured that no transformation of references will be needed when a \lstinline!choice! is applied, and that applicability of a \lstinline!choice! does not depend on context, see \cref{global-name-lookup}.
+\end{nonnormative}
 
 This is a hint for users of the model, and can also be used by the user interface to suggest reasonable redeclaration, where the string comments on the choice declaration can be used as textual explanations of the choices.
 The annotation is not restricted to replaceable elements but can also be applied to non-replaceable elements, enumeration types, and simple variables.
@@ -1143,7 +1149,8 @@ \subsection{Annotations for Redeclaration and Modification}\label{annotation-cho
 parameter Boolean useHeatPort = false annotation(choices(checkBox = true));
 \end{lstlisting}
 \end{example}
-\section{Selective Model Extension}\label{selective-model-extension}
+
+\section{Selective Model Extension}\label{selective-model-extension}\index{deselection!selective model extension}
 \begin{nonnormative}
 The goal of selective model extension is to enable unforeseen structural variability without requiring deliberately prepared base-models, \textcite{Buerger2019SelectiveModel}.
 
@@ -1161,6 +1168,7 @@ \section{Selective Model Extension}\label{selective-model-extension}
   $\ldots$
 end C;
 \end{lstlisting}
+\index{break@\robustinline{break}!deselection}
 The semantic rules are:
 \begin{enumerate}
 \item The deselection \lstinline!break $D$! is applied before any other, non selective model extension related, modifications of \lstinline!B! in \lstinline!C!.
diff --git a/chapters/interface.tex b/chapters/interface.tex
index c45b0074c..760f97b62 100644
--- a/chapters/interface.tex
+++ b/chapters/interface.tex
@@ -1,7 +1,7 @@
 \chapter{Interface or Type Relationships}\label{interface-or-type-relationships}
 
-A class or component, e.g.\ denoted \lstinline!A!, can in some cases be used at a
-location designed for another class or component, e.g.\ denoted \lstinline!B!. In
+A class or component, e.g., denoted \lstinline!A!, can in some cases be used at a
+location designed for another class or component, e.g., denoted \lstinline!B!. In
 Modelica this is the case for replaceable classes (see \cref{redeclaration}) and
 for \lstinline!inner!/\lstinline!outer! elements (see \cref{instance-hierarchy-name-lookup-of-inner-declarations}).
 Replaceable classes are the
@@ -13,7 +13,7 @@ \chapter{Interface or Type Relationships}\label{interface-or-type-relationships}
 
 \section{Interface Terminology}\label{interface-terminology}
 
-In this chapter, two kinds of terminology are used for identical concepts to get better understanding (e.g.\ by both engineers and computer scientists).
+In this chapter, two kinds of terminology are used for identical concepts to get better understanding (e.g., by both engineers and computer scientists).
 A short summary of the terms is given in the following table.
 The details are defined in the rest of this chapter.
 
@@ -22,7 +22,7 @@ \section{Interface Terminology}\label{interface-terminology}
 that is needed to decide whether \lstinline!A! can be used instead of \lstinline!B!.
 \par
 \begin{nonnormative*}
-E.g.\ a declaration \lstinline!Real x! is part of the type (also called \emph{interface}), but \lstinline!import A! is not.
+E.g., a declaration \lstinline!Real x! is part of the type (also called \emph{interface}), but \lstinline!import A! is not.
 \end{nonnormative*}
 \end{definition}
 
@@ -47,7 +47,7 @@ \section{Interface Terminology}\label{interface-terminology}
 \lstinline!A! is a restricted subtype of \lstinline!B!, or equivalently, the interface of \lstinline!A! is plug compatible to the interface of \lstinline!B!, if \lstinline!A! is a subtype of
 \lstinline!B! and if connector components in \lstinline!A! that are not in \lstinline!B!, are default connectable.
 \begin{nonnormative}
-E.g.\ it is not allowed that these connectors have variables with the \lstinline!input! prefix, because then they must be connected.
+E.g., it is not allowed that these connectors have variables with the \lstinline!input! prefix, because then they must be connected.
 \end{nonnormative}
 A model or block \lstinline!A! cannot be used instead of \lstinline!B!, if the particular situation does not allow to make a connection to these additional connectors. In such a case the stricter
 \emph{plug compatible} is required for a redeclaration.
@@ -59,7 +59,7 @@ \section{Interface Terminology}\label{interface-terminology}
 \lstinline!B! is called.
 \par
 \begin{nonnormative*}
-E.g.\ an additional argument must have a default value.
+E.g., an additional argument must have a default value.
 \end{nonnormative*}
 \end{definition}
 
@@ -67,7 +67,7 @@ \section{The Concepts of Type, Interface and Subtype}\label{the-concepts-of-type
 
 A \emph{type} can conceptually be viewed as a \emph{set of values}. When
 we say that the variable \lstinline!x! has the type \lstinline!Real!, we mean that the value of
-\lstinline!x! belongs to the set of values represented by the type \lstinline!Real! i.e.,
+\lstinline!x! belongs to the set of values represented by the type \lstinline!Real!, i.e.,
 roughly the set of floating point numbers representable by \lstinline!Real!, for the
 moment ignoring the fact that \lstinline!Real! is also viewed as a class with
 certain attributes. Analogously, the variable \lstinline!b! having \lstinline!Boolean! type
@@ -92,7 +92,7 @@ \section{The Concepts of Type, Interface and Subtype}\label{the-concepts-of-type
 
 An element is characterized by its interface defined by some attributes
 (\cref{interface-or-type}). The \emph{type} of the element is the set of values
-having the same interface, i.e.\ the same attributes.
+having the same interface, i.e., the same attributes.
 
 A \emph{subtype} \lstinline!A1! in relation to another type \lstinline!A!, means that the
 elements of the set corresponding to \lstinline!A1! is a subset of the set
@@ -102,13 +102,13 @@ \section{The Concepts of Type, Interface and Subtype}\label{the-concepts-of-type
 \begin{example}
 A record \lstinline!R!: \lstinline!record R Boolean b; Real x; end R;!
 
-Another record called \lstinline!R2!: \lstinline!R2 Boolean b; Real x; Real y; end R2;!
+Another record called \lstinline!R2!: \lstinline!record R2 Boolean b; Real x; Real y; end R2;!
 
 An instance \lstinline!r!: \lstinline!R r;!
 
 An instance \lstinline!r2!: \lstinline!R2 r2;!
 
-The type \lstinline!R! of \lstinline!r! can be viewed as the set of all record values having the attributes defined by the interface of \lstinline!R!, e.g.\ the infinite set \{\lstinline!R(b=false, x=1.2)!, \lstinline!R(b=false, x=3.4)!, \lstinline!R(b=true, x=1.2)!, \lstinline!R(b=true, x=1.2, y=2)!, \lstinline!R(b=true, x=1.2, a=2)!, $\ldots$\}.
+The type \lstinline!R! of \lstinline!r! can be viewed as the set of all record values having the attributes defined by the interface of \lstinline!R!, e.g., the infinite set \{\lstinline!R(b=false, x=1.2)!, \lstinline!R(b=false, x=3.4)!, \lstinline!R(b=true, x=1.2)!, \lstinline!R(b=true, x=1.2, y=2)!, \lstinline!R(b=true, x=1.2, a=2)!, $\ldots$\}.
 The statement that \lstinline!r! has the type (or interface) \lstinline!R! means that the value of \lstinline!r! s to this infinite set.
 
 The type \lstinline!R2! is a subtype of \lstinline!R! since its instances
@@ -165,7 +165,7 @@ \section{Interface or Type}\label{interface-or-type}
     \lstinline!IntegerType!, \lstinline!StringType! or \lstinline!BooleanType!).
   \end{itemize}
 \item
-  Only for an \lstinline!operator record! class and classes derived from \lstinline!ExternalObject!: the full name of the operator record base class (i.e.\ the one containing the operations), or the derived class.
+  Only for an \lstinline!operator record! class and classes derived from \lstinline!ExternalObject!: the full name of the operator record base class (i.e., the one containing the operations), or the derived class.
   See \cref{overloaded-operators} and \cref{external-objects}.
 
   The following item does not apply for an \lstinline!operator record! class or class derived from \lstinline!ExternalObject!, since the type is already uniquely defined by the full name.
@@ -194,7 +194,7 @@ \section{Interface or Type}\label{interface-or-type}
 
 \begin{nonnormative}
 The public interface does not contain all of the information about the class or component.
-When using a class as a base class we also need protected elements, and for internal type-checking we need e.g.\ import-elements.
+When using a class as a base class we also need protected elements, and for internal type-checking we need, e.g., import-elements.
 However, the information is sufficient for checking compatibility and for using the class to flatten components.
 \end{nonnormative}
 
@@ -205,19 +205,19 @@ \subsection{Transitively Non-Replaceable}\label{transitively-non-replaceable}
 Such classes are defined as \willintroduce{transitively non-replaceable}.
 \end{nonnormative}
 
-A class reference is \firstuse{transitively non-replaceable} iff (i.e.\ \emph{if and only if}) all parts of the name satisfy the following:
+A class reference is \firstuse{transitively non-replaceable} iff (i.e., \emph{if and only if}) all parts of the name satisfy the following:
 \begin{itemize}
 \item
   If the class definition is long it is transitively non-replaceable if
   not declared replaceable.
 \item
-  If the class definition is short (i.e.\ \lstinline!class A = P.B!) it is
+  If the class definition is short (i.e., \lstinline!class A = P.B!) it is
   transitively non-replaceable if it is non-replaceable and equal to
   class reference (\lstinline!P.B!) that is transitively non-replaceable.
 \end{itemize}
 
 \begin{nonnormative}
-According to \cref{restrictions-on-base-classes-and-constraining-types-to-be-transitively-non-replaceable}, for a hierarchical name all parts of the name must be transitively non-replaceable, i.e.\ in \lstinline!extends A.B.C! this implies that \lstinline!A.B.C! must be transitively non-replaceable, as well as \lstinline!A! and \lstinline!A.B!, with the exception of the \emph{class extends redeclaration mechanism} see \cref{the-class-extends-redeclaration-mechanism}.
+According to \cref{restrictions-on-base-classes-and-constraining-types-to-be-transitively-non-replaceable}, for a hierarchical name all parts of the name must be transitively non-replaceable, i.e., in \lstinline!extends A.B.C! this implies that \lstinline!A.B.C! must be transitively non-replaceable, as well as \lstinline!A! and \lstinline!A.B!, with the exception of the \emph{class extends redeclaration mechanism} see \cref{the-class-extends-redeclaration-mechanism}.
 \end{nonnormative}
 
 \subsection{Inheritance Interface or Class Type}\label{inheritance-interface-or-class-type}
@@ -332,7 +332,7 @@ \section{Interface Compatibility or Subtyping}\label{interface-compatibility-or-
   \item
     Declared variability is ordered \lstinline!constant! \textless{} \lstinline!parameter! \textless{} \lstinline!discrete! \textless{} continuous-time (\lstinline!Real! without prefix), and \lstinline!A! is only compatible with \lstinline!B! if the declared variability in \lstinline!A! is less than or equal the variability in \lstinline!B!.
     \begin{nonnormative}
-    For a redeclaration of an element the variability prefix is as default inherited by the redeclaration (i.e.\ no need to repeat \lstinline!parameter! when redeclaring a parameter).
+    For a redeclaration of an element the variability prefix is as default inherited by the redeclaration (i.e., no need to repeat \lstinline!parameter! when redeclaring a parameter).
     \end{nonnormative}
   \item
     The \lstinline!input! and \lstinline!output! prefixes must be matched.  This ensures that the rules regarding inputs/outputs for matching connectors and (non-connector inputs) are preserved, as well as the restriction on blocks.
@@ -588,14 +588,14 @@ \section{Type Compatible Expressions}\label{type-compatible-expressions}
 Certain expressions consist of an operator applied to two or more subexpressions (\lstinline!A! and \lstinline!B!).
 This includes:
 \begin{itemize}
-\item \lstinline!if!-expressions, e.g.\ \lstinline!if x then A else B!.
-\item Array expressions, e.g.\ \lstinline!{A, B}!
-\item Binary operators if both operands are of simple types, e.g.\ \lstinline!A + B!.
+\item \lstinline!if!-expressions, e.g., \lstinline!if x then A else B!.
+\item Array expressions, e.g., \lstinline!{A, B}!
+\item Binary operators if both operands are of simple types, e.g., \lstinline!A + B!.
 Binary operators for other types are only defined for operator records, \cref{overloaded-binary-operations}, and do not necessarily require that the operands are type compatible with each other.
 \end{itemize}
 If the subexpressions satisfy the following restrictions they are called type compatible expressions.
 Otherwise the expression is illegal.
-The type of the full expression (e.g.\ \lstinline!if x then A else B!) is also defined below.
+The type of the full expression (e.g., \lstinline!if x then A else B!) is also defined below.
 \begin{itemize}
 \item
   If \lstinline!A! is a record expression, \lstinline!B! must also be a record expression with the same named elements.
@@ -628,8 +628,8 @@ \section{Type Compatible Expressions}\label{type-compatible-expressions}
   The enumeration expressions must be defined in terms of an enumeration type with the same enumeration literals in the same order.
 \item
   For array and \lstinline!if!-expressions, if \lstinline!A! has an \lstinline!operator record! base class then \lstinline!B! must also have an \lstinline!operator record! base class, and it must be the same, and otherwise neither \lstinline!A! nor \lstinline!B! may have an \lstinline!operator record! base class.
-  This is also the \lstinline!operator record! base class for the full expression e.g.\ for \lstinline!if (cond) then A else B!.
+  This is also the \lstinline!operator record! base class for the full expression, e.g., for \lstinline!if (cond) then A else B!.
 \item
   If \lstinline!A! is derived from \lstinline!ExternalObject! then \lstinline!B! must also be derived from \lstinline!ExternalObject! and they must have the same full name; and otherwise neither \lstinline!A! nor \lstinline!B! may be derived from \lstinline!ExternalObject!.
-  The common full name also defines the type of the full expression, e.g.\ for \lstinline!if (cond) then A else B!.
+  The common full name also defines the type of the full expression, e.g., for \lstinline!if (cond) then A else B!.
 \end{itemize}
diff --git a/chapters/introduction.tex b/chapters/introduction.tex
index 67f699731..800050b7f 100644
--- a/chapters/introduction.tex
+++ b/chapters/introduction.tex
@@ -52,7 +52,7 @@ \section{Scope of the Specification}\label{scope-of-the-specification}
 Therefore, a flat hybrid DAE is seen as a set of equations where some of the equations are only conditionally evaluated.
 Initial setup of the model is specified using \lstinline!start!-attributes and equations that hold only during initialization.
 
-A Modelica class may also contain annotations, i.e.\ formal comments, which specify graphical representations of the class (icon and diagram), documentation text for the class, and version information.
+A Modelica class may also contain annotations, i.e., formal comments, which specify graphical representations of the class (icon and diagram), documentation text for the class, and version information.
 
 \section{Some Definitions}\label{some-definitions}
 
@@ -93,7 +93,7 @@ \section{Some Definitions}\label{some-definitions}
 The model can be analyzed in ways other than simulation, e.g., linearization, and parameter estimation, but they are not described in the specification.
 \end{nonnormative}
 
-\begin{definition}[Translation]\index{translation}
+\begin{definition}[Translation]\index{translation!of simulation model}
 Translation is the process of preparing a Modelica simulation model for simulation, starting with flattening but not including the simulation itself.
 \end{definition}
 
@@ -130,6 +130,9 @@ \section{Notation}\label{notation}
 It is common to mix Modelica code with mathematical notation.
 For example, \lstinline!average($x$, $y$)! could be defined as $\frac{x + y}{2}$.
 
+Inline code fragments are sometimes surrounded by quotes to clearly mark their beginning and end, or to emphasize separation from the surrounding text.
+For example, `\lstinline!,!' is used to separate the arguments of a function call.
+
 \begin{definition}[Something]% Do not add this one to the index!
 Text defining the meaning of \emph{something}.
 \end{definition}
diff --git a/chapters/lexicalstructure.tex b/chapters/lexicalstructure.tex
index 57566e5f3..515a6ab24 100644
--- a/chapters/lexicalstructure.tex
+++ b/chapters/lexicalstructure.tex
@@ -71,7 +71,7 @@ \subsection{Identifiers}\label{identifiers}
 Modelica \firstuse[identifier]{identifiers}, used for naming classes, variables, constants, and other items, are of two forms.
 The first form always starts with a letter or underscore (`\_'), followed by any number of letters, digits, or underscores.
 Case is significant, i.e., the identifiers \lstinline!Inductor! and \lstinline!inductor! are different.
-The second form (\lstinline[language=grammar]!Q-IDENT!) starts with a single quote, followed by a sequence of any printable ASCII character, where single-quote must be preceded by backslash, and terminated by a single quote, e.g.\ \lstinline!'12H'!, \lstinline!'13\'H'!, \lstinline!'+foo'!.
+The second form (\lstinline[language=grammar]!Q-IDENT!) starts with a single quote, followed by a sequence of any printable ASCII character, where single-quote must be preceded by backslash, and terminated by a single quote, e.g., \lstinline!'12H'!, \lstinline!'13\'H'!, \lstinline!'+foo'!.
 Control characters in quoted identifiers have to use string escapes.
 The single quotes are part of the identifier, i.e., \lstinline!'x'! and \lstinline!x! are distinct identifiers.
 The redundant escapes (\lstinline!'\?'! and \lstinline!'\"'!) are the same as the corresponding non-escaped variants (\lstinline!'?'! and \lstinline!'"'!), but are only for use in Modelica source code.
@@ -112,7 +112,7 @@ \subsection{Names}\label{names}
 
 \subsection{Modelica Keywords}\label{modelica-keywords}
 
-The following Modelica \firstuse[keyword]{keywords} are reserved words and shall not be used as identifiers:
+The following Modelica \firstuse[keyword]{keywords} are reserved words that cannot be used where \lstinline[language=grammar]!IDENT! is expected in the language grammar (\cref{modelica-concrete-syntax}):
 \begin{center}
 \begin{tabular}{l l l l l}
 {\lstinline!algorithm!} & {\lstinline!discrete!} & {\lstinline!false!} & {\lstinline!loop!} & {\lstinline!pure!}\\ \hline
@@ -130,6 +130,20 @@ \subsection{Modelica Keywords}\label{modelica-keywords}
 \end{tabular}
 \end{center}
 
+In particular, it is not allowed to declare an element or enumeration literal with these names.
+This also applies to the identifiers that name the predefined types \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, and \lstinline!String!, see \cref{predefined-types-and-classes}.
+
+\begin{example}
+Not all predefined types have names with restrictions:
+\begin{lstlisting}[language=modelica]
+type StateSelect = enumeration(one, two);
+StateSelect s = StateSelect.one;          // OK, using local StateSelect.
+Real x(stateSelect = StateSelect.never);  // Error: 'never' is not a literal
+                                          // of StateSelect.
+Real y(stateSelect = .StateSelect.never); // OK, using predefined StateSelect.
+\end{lstlisting}
+\end{example}
+
 \section{Literal Constants}\label{literal-constants}
 
 \firstuse[literal (constant)]{Literals} (or \firstuse[---]{literal constants}) are unnamed constants used to build expressions, and have different forms depending on their type.
@@ -157,7 +171,7 @@ \subsection{Floating Point Numbers}\label{floating-point-numbers}
 
 \subsection{Integer Literals}\label{integer-literals}
 
-Literals of type \lstinline!Integer! are sequences of decimal digits, e.g.\ as in the integer numbers \lstinline!33!,
+Literals of type \lstinline!Integer! are sequences of decimal digits, e.g., as in the integer numbers \lstinline!33!,
 % Just a '0' doesn't work in \lstinline as reported in (closed as fixed on 2021-09-07):
 % - https://github.com/brucemiller/LaTeXML/issues/1651 -- fixed on 'master'
 \ifpdf
@@ -211,7 +225,7 @@ \subsection{Strings}\label{strings}
 \end{lstlisting}
 
 Concatenation of string literals in certain situations (see the Modelica
-grammar) is denoted by the + operator in Modelica, e.g.\ \lstinline!"a"! + \lstinline!"b"!
+grammar) is denoted by the + operator in Modelica, e.g., \lstinline!"a"! + \lstinline!"b"!
 becomes \lstinline!"ab"!. This is useful for expressing long string literals that
 need to be written on several lines.
 
diff --git a/chapters/library.tex b/chapters/library.tex
index 1031ee3ce..bcc2e1a0b 100644
--- a/chapters/library.tex
+++ b/chapters/library.tex
@@ -11,7 +11,7 @@ \chapter{The Modelica Standard Library}\label{the-modelica-standard-library}
 commercial Modelica simulation environments. The Modelica Standard
 Library is tool-neutral, and relies on a small library,
 ModelicaServices, that each conformant tool must implement to handle
-tool-specific couplings e.g.\ for animation. Furthermore, other people
+tool-specific couplings, e.g., for animation. Furthermore, other people
 and organizations are developing free and commercial Modelica libraries.
 For information about these libraries and for downloading the free
 libraries see \url{https://modelica.org/libraries/}.
diff --git a/chapters/operatorsandexpressions.tex b/chapters/operatorsandexpressions.tex
index 39cb64c22..8dbf40146 100644
--- a/chapters/operatorsandexpressions.tex
+++ b/chapters/operatorsandexpressions.tex
@@ -166,7 +166,7 @@ \section{Operator Precedence and Associativity}\label{operator-precedence-and-as
 
 \section{Evaluation Order}\label{evaluation-order}
 
-A tool is free to solve equations, reorder expressions and to not evaluate expressions if their values do not influence the result (e.g.\ short-circuit evaluation of \lstinline!Boolean! expressions).
+A tool is free to solve equations, reorder expressions and to not evaluate expressions if their values do not influence the result (e.g., short-circuit evaluation of \lstinline!Boolean! expressions).
 \lstinline!if!-statements and \lstinline!if!-expressions guarantee that their branches are only evaluated if the appropriate condition is true, but relational operators generating state or time events will during continuous integration have the value from the most recent event.
 
 If a numeric operation overflows the result is undefined.
@@ -292,7 +292,7 @@ \section{Equality, Relational, and Logical Operators}\label{equality-relational-
 \item
   In relations of the form \lstinline!v1 == v2 or v1 <> v2!, \lstinline!v1! or \lstinline!v2! shall, unless used in a function, not be a subtype of \lstinline!Real!.
   \begin{nonnormative}
-  The reason for this rule is that relations with \lstinline!Real! arguments are transformed to state events (see \cref{events-and-synchronization}) and this transformation becomes unnecessarily complicated for the \lstinline!==! and \lstinline!<>! relational operators (e.g.\ two crossing functions instead of one crossing function needed, epsilon strategy needed even at event instants).
+  The reason for this rule is that relations with \lstinline!Real! arguments are transformed to state events (see \cref{events-and-synchronization}) and this transformation becomes unnecessarily complicated for the \lstinline!==! and \lstinline!<>! relational operators (e.g., two crossing functions instead of one crossing function needed, epsilon strategy needed even at event instants).
   Furthermore, testing on equality of \lstinline!Real! variables is questionable on machines where the number length in registers is different to number length in main memory.
   \end{nonnormative}
 \item
@@ -404,7 +404,7 @@ \section{Built-in Intrinsic Operators with Function Syntax}\label{built-in-intri
 
 \subsection{Numeric Functions and Conversion Functions}\label{numeric-functions-and-conversion-functions}
 
-The mathematical functions and conversion operators are listed below do not generate events.
+The mathematical functions and conversion operators listed below do not generate events.
 \begin{center}
 \begin{tabular}{l|l l}
 \hline
@@ -493,19 +493,17 @@ \subsection{Numeric Functions and Conversion Functions}\label{numeric-functions-
 
 \begin{operatordefinition*}[String]\label{modelica:to-String}\index{String@\robustinline{String}!conversion operator}
 \begin{synopsis}\begin{lstlisting}
-String($b$, <options>)
-String($i$, <options>)
-String($r$, significantDigits = $d$, <options>)
+String($b$, $\langle$$\mbox{\emph{options}}$$\rangle$)
+String($i$, $\langle$$\mbox{\emph{options}}$$\rangle$)
+String($i$, format = $s$)
+String($r$, $\langle$$\mbox{\emph{options}}$$\rangle$)
 String($r$, format = $s$)
-String($e$, <options>)
+String($e$, $\langle$$\mbox{\emph{options}}$$\rangle$)
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
 Convert a scalar non-\lstinline!String! expression to a \lstinline!String! representation.
-The first argument may be a \lstinline!Boolean! $b$, an \lstinline!Integer! $i$, a \lstinline!Real! $r$ or an enumeration value $e$ (\cref{type-conversion-of-enumeration-values-to-string-or-integer}).
-The other arguments must use named arguments.
-For \lstinline!Real! expressions the output shall be according to the Modelica grammar.
-
-The optional \lstinline!<options>! are:
+The first argument may be a \lstinline!Boolean! $b$, an \lstinline!Integer! $i$, a \lstinline!Real! $r$, or an enumeration value $e$ (\cref{type-conversion-of-enumeration-values-to-string-or-integer}).
+The $\langle\mathit{options}\rangle$ represent zero or more of the following named arguments (that cannot be passed as positional arguments):
 \begin{itemize}
 \item
   \lstinline!Integer minimumLength = 0!: Minimum length of the resulting string.
@@ -514,13 +512,19 @@ \subsection{Numeric Functions and Conversion Functions}\label{numeric-functions-
   \lstinline!Boolean leftJustified = true!: If true, the converted result is left justified in the string; if false it is right justified in the string.
 \item
   \lstinline!Integer significantDigits = 6!: Number of significant digits in the result string.
+  Only allowed when formatting a \lstinline!Real! value.
 \end{itemize}
 
+The standard type coercion described in \cref{standard-type-coercion} shall not be applied for the first argument of \lstinline!String!.
+Hence, specifying \lstinline!significantDigits! is an error when the first argument of \lstinline!String! is an \lstinline!Integer! expression.
+
+For \lstinline!Real! expressions the output shall be according to the Modelica grammar.
+
 \begin{nonnormative}
 Examples of \lstinline!Real! values formatted with 6 significant digits: \emph{12.3456}, \emph{0.0123456}, \emph{12345600}, \emph{1.23456E-10}.
 \end{nonnormative}
 
-The \lstinline!format! string corresponding to \lstinline!<options>! is:
+The \lstinline!format! string corresponding to $\langle\mathit{options}\rangle$ is:
 \begin{itemize}
 \item
   For \lstinline!Real!:\\
@@ -531,12 +535,27 @@ \subsection{Numeric Functions and Conversion Functions}\label{numeric-functions-
   \lstinline!(if leftJustified then "-" else "") + String(minimumLength) + "d"!
 \end{itemize}
 
-Form of the \lstinline!format! string:
-According to ANSI-C the format string specifies one conversion specifier (excluding the leading \%), shall not contain length modifiers, and shall not use `\lstinline!*!' for width and/or precision.
-For all numeric values the format specifiers `\lstinline!f!', `\lstinline!e!', `\lstinline!E!', `\lstinline!g!', `\lstinline!G!' are allowed.
-For integral values it is also allowed to use the `\lstinline!d!', `\lstinline!i!', `\lstinline!o!', `\lstinline!x!', `\lstinline!X!', `\lstinline!u!', and `\lstinline!c!' format specifiers (for non-integral values a tool may round, truncate or use a different format if the integer conversion characters are used).
+The ANSI-C style \lstinline!format! string (which cannot be combined with any of the other named arguments) consists of a single conversion specification without the leading \%.
+It shall not contain a length modifier, and shall not use `\lstinline!*!' for width and/or precision.
+For both \lstinline!Real! and \lstinline!Integer! values, the conversion specifiers `\lstinline!f!', `\lstinline!e!', `\lstinline!E!', `\lstinline!g!', `\lstinline!G!' are allowed.
+For \lstinline!Integer! values it is also allowed to use the `\lstinline!d!', `\lstinline!i!', `\lstinline!o!', `\lstinline!x!', `\lstinline!X!', `\lstinline!u!', and `\lstinline!c!' conversion specifiers.
+Using the \lstinline!Integer! conversion specifiers for a \lstinline!Real! value is a deprecated feature, where tools are expected to produce a result by either rounding the value, truncating the value, or picking one of the \lstinline!Real! conversion specifiers instead.
 
 The `\lstinline!x!'/`\lstinline!X!' formats (hexa-decimal) and \lstinline!c! (character) for \lstinline!Integer! values give results that do not agree with the Modelica grammar.
+
+\begin{example}
+Some situations worth a remark:
+\begin{itemize}
+\item
+  \lstinline!String(4.0, format = "g")! produces \emph{4} which is not a valid \lstinline!Real! literal.
+  However, it is an \lstinline!Integer! literal that can be used almost anywhere in Modelica code instead of the \lstinline!Real! literal \lstinline{4.0} (with the first argument to \lstinline!String! being a notable exception here).
+\item
+  \lstinline!String(4, format = ".3f")! uses the \lstinline!Integer! case of \lstinline!String! since no automatic type coerction takes place for the first argument.
+  An implementation may internally convert the value to floating point and then fall back on the \lstinline!Real! case implementation of \lstinline!format = ".3f"!.
+\item
+  \lstinline!String(4611686018427387648, format = ".0f")! (a valid \lstinline!Integer! value in an implementation with 64 bit \lstinline!IntegerType!) may produce \emph{4611686018427387904} (not equal to input value), in case internal conversion to a 64 bit \lstinline[language=C]!double! is applied.
+\end{itemize}
+\end{example}
 \end{semantics}
 \end{operatordefinition*}
 
@@ -561,7 +580,7 @@ \subsection{Event Triggering Mathematical Functions}\label{event-triggering-math
 \end{center}
 
 These expression for \lstinline!div!, \lstinline!ceil!, \lstinline!floor!, and \lstinline!integer! are event generating expression.
-The event generating expression for \lstinline!mod(x,y)! is \lstinline!floor(x/y)!, and for \lstinline!rem(x,y)! it is \lstinline!div(x,y)! -- i.e.\ events are not generated when \lstinline!mod! or \lstinline!rem! changes continuously in an interval, but when they change discontinuously from one interval to the next.
+The event generating expression for \lstinline!mod(x,y)! is \lstinline!floor(x/y)!, and for \lstinline!rem(x,y)! it is \lstinline!div(x,y)! -- i.e., events are not generated when \lstinline!mod! or \lstinline!rem! changes continuously in an interval, but when they change discontinuously from one interval to the next.
 
 \begin{nonnormative}
 If this is not desired, the \lstinline!noEvent! operator can be applied to them.
@@ -750,7 +769,7 @@ \subsection{Derivative and Special Purpose Operators with Function Syntax}\label
 Evaluates to \lstinline!$\mathit{expr}$(time - $\mathit{delayTime}$)! for $\text{\lstinline!time!} > \text{\lstinline!time.start!} + \mathit{delayTime}$ and \lstinline!$\mathit{expr}$(time.start)! for $\text{\lstinline!time!} \leq \text{\lstinline!time.start!} + \mathit{delayTime}$.
 The arguments, i.e., $\mathit{expr}$, $\mathit{delayTime}$ and $\mathit{delayMax}$, need to be subtypes of \lstinline!Real!.
 $\mathit{delayMax}$ needs to be additionally a parameter expression.
-The following relation shall hold: $0 < \mathit{delayTime} \leq \mathit{delayMax}$, otherwise an error occurs.
+The following relation shall hold: $0 \leq \mathit{delayTime} \leq \mathit{delayMax}$, otherwise an error occurs.
 If $\mathit{delayMax}$ is not supplied in the argument list, $\mathit{delayTime}$ needs to be a parameter expression.
 For non-scalar arguments the function is vectorized according to \cref{vectorized-calls-of-functions}.
 For further details, see \cref{delay}.
@@ -1047,7 +1066,7 @@ \subsubsection{homotopy}\label{homotopy}
 \lstinline!homotopy! is, however used on a variable that is an ``input'' to the non-linear algebraic equation system, and modifies the characteristics of the non-linear algebraic equation system.
 The only useful way is to perform the homotopy iteration over $f_1$ and $f_2$ together.
 
-The suggested approach is ``conceptual'', because more efficient implementations are possible, e.g.\ by determining the smallest iteration loop, that contains the equations of the first BLT block in which \lstinline!homotopy! is present and all equations up to the last BLT block that describes a non-linear algebraic equation system.
+The suggested approach is ``conceptual'', because more efficient implementations are possible, e.g., by determining the smallest iteration loop, that contains the equations of the first BLT block in which \lstinline!homotopy! is present and all equations up to the last BLT block that describes a non-linear algebraic equation system.
 
 A trivial implementation of \lstinline!homotopy! is obtained by defining the following function in the global scope:
 \begin{lstlisting}[language=modelica]
@@ -1222,7 +1241,7 @@ \subsubsection{getInstanceName}\label{getinstancename}
 If \lstinline!MyLib.Vehicle! is simulated, the call of \lstinline!getInstanceName()! returns \lstinline!"Vehicle.engine.controller"!.
 \end{example}
 
-If this function is not called inside a model or block (e.g.\ the function is called in a function or in a constant of a package), the return value is not specified.
+If this function is not called inside a model or block (e.g., the function is called in a function or in a constant of a package), the return value is not specified.
 
 \begin{nonnormative}
 The simulation result should not depend on the return value of this function.
@@ -1292,7 +1311,7 @@ \subsection{Event-Related Operators with Function Syntax}\label{event-related-op
 smooth($p$, $\mathit{expr}$)
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-If $p \geq 0$ \lstinline!smooth($p$, $\mathit{expr}$)! returns $\mathit{expr}$ and states that $\mathit{expr}$ is $p$ times continuously differentiable, i.e.: $\mathit{expr}$ is continuous in all \lstinline!Real! variables appearing in the expression and all partial derivatives with respect to all appearing real variables exist and are continuous up to order $p$.
+If $p \geq 0$ \lstinline!smooth($p$, $\mathit{expr}$)! returns $\mathit{expr}$ and states that $\mathit{expr}$ is $p$ times continuously differentiable, i.e., $\mathit{expr}$ is continuous in all \lstinline!Real! variables appearing in the expression and all partial derivatives with respect to all appearing real variables exist and are continuous up to order $p$.
 The argument $p$ should be a scalar \lstinline!Integer! parameter expression.
 The only allowed types for $\mathit{expr}$ in \lstinline!smooth! are: \lstinline!Real! expressions, arrays of allowed expressions, and records containing only components of allowed expressions.
 
@@ -1366,7 +1385,7 @@ \subsection{Event-Related Operators with Function Syntax}\label{event-related-op
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
 Expands into \lstinline!($b$ and not pre($b$))! for \lstinline!Boolean! variable $b$.
-The same restrictions as for \lstinline!pre! apply (e.g.\ not to be used in \lstinline!function! classes).
+The same restrictions as for \lstinline!pre! apply (e.g., not to be used in \lstinline!function! classes).
 \end{semantics}
 \end{operatordefinition}
 
@@ -1400,7 +1419,7 @@ \subsection{Event-Related Operators with Function Syntax}\label{event-related-op
 \section{Variability of Expressions}\label{variability-of-expressions}
 
 The concept of \firstuse[expression variability]{variability of an expression}\index{variability!expression|see{expression variability}} indicates to what extent the expression can vary over time.
-See also \cref{component-variability-prefixes-discrete-parameter-constant} regarding the concept of variability.
+See also \cref{component-variability} regarding the concept of variability.
 % It seems wrong to not mention 'clocked discrete-time' here.
 There are four levels of variability of expressions, starting from the least variable:
 \begin{itemize}
@@ -1481,7 +1500,7 @@ \subsection{Constant Expressions}\label{constant-expressions}
 \item
   \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, \lstinline!String!, and \lstinline!enumeration! literals.
 \item
-  Constant variables, see \cref{component-variability-prefixes-discrete-parameter-constant}.
+  Constant variables, see \cref{component-variability}.
 \item
   Except for the special built-in operators \lstinline!initial!, \lstinline!terminal!, \lstinline!der!,
   \lstinline!edge!, \lstinline!change!, \lstinline!sample!, and \lstinline!pre!, a function or operator with constant
@@ -1495,29 +1514,27 @@ \subsection{Constant Expressions}\label{constant-expressions}
   \end{itemize}
 \end{itemize}
 
-\subsection{Parameter Expressions}\label{parameter-expressions}
+\subsection{Evaluable Expressions}\label{evaluable-expressions}
 
-Parameter expressions\index{parameter!expression}\index{expression variability!parameter}\index{parametric variability|see{parameter, expression}} are:
+Evaluable expressions\index{evaluable expression}\index{expression variability!evaluable} are:
 \begin{itemize}
 \item
   Constant expressions.
 \item
-  Parameter variables, see \cref{component-variability-prefixes-discrete-parameter-constant}.
+  Evaluable parameter variables, see \cref{component-variability}.
 \item
-  Input variables in functions behave as though they were parameter expressions.
+  Input variables in functions behave as though they were evaluable expressions.
 \item
-  Except for the special built-in operators \lstinline!initial!, \lstinline!terminal!, \lstinline!der!,
-  \lstinline!edge!, \lstinline!change!, \lstinline!sample!, and \lstinline!pre!, a function or operator with parameter
-  subexpressions is a parameter expression.
+  Except for the special built-in operators \lstinline!initial!, \lstinline!terminal!, \lstinline!der!, \lstinline!edge!, \lstinline!change!, \lstinline!sample!, and \lstinline!pre!, a function or operator with evaluable subexpressions is an evaluable expression.
 \item
-  Some function calls are parameter expressions even if the arguments are not:
+  The sub-expression \lstinline!end! used in \lstinline!A[$\ldots$ end $\ldots$]! if \lstinline!A! is a variable declared in a non-\lstinline!function! class.
+\item
+  Some function calls are evaluable expressions even if the arguments are not:
   \begin{itemize}
   \item
     \lstinline!cardinality(c)!, see restrictions for use in \cref{cardinality-deprecated}.
   \item
-    \lstinline!end! in \lstinline!A[$\ldots$ end $\ldots$]! if \lstinline!A! is variable declared in a non-\lstinline!function! class.
-  \item
-    \lstinline!size(A)! (including \lstinline!size(A, j)! where \lstinline!j! is parameter expression) if \lstinline!A! is variable declared in a non-function class.
+    \lstinline!size(A)! (including \lstinline!size(A, j)! where \lstinline!j! is an evaluable expression) if \lstinline!A! is variable declared in a non-function class.
   \item
     \lstinline!Connections.isRoot(A.R)!
   \item
@@ -1525,6 +1542,26 @@ \subsection{Parameter Expressions}\label{parameter-expressions}
   \end{itemize}
 \end{itemize}
 
+\subsection{Parameter Expressions}\label{parameter-expressions}
+
+Parameter expressions\index{parameter!expression}\index{expression variability!parameter}\index{parametric variability|see{parameter, expression}} are:
+\begin{itemize}
+\item
+  Evaluable expressions.
+\item
+  Non-evaluable parameter variables, see \cref{component-variability}.
+\item
+  Except for the special built-in operators \lstinline!initial!, \lstinline!terminal!, \lstinline!der!,
+  \lstinline!edge!, \lstinline!change!, \lstinline!sample!, and \lstinline!pre!, a function or operator with parameter
+  subexpressions is a parameter expression.
+\item
+  Some function calls are parameter expressions even if the arguments are not:
+  \begin{itemize}
+  \item
+    \lstinline!size(A, j)! where \lstinline!j! is a parameter expression, if \lstinline!A! is variable declared in a non-function class.
+  \end{itemize}
+\end{itemize}
+
 \subsection{Discrete-Time Expressions}\label{discrete-time-expressions}
 
 Discrete-time expressions\index{discrete-time!expression}\index{expression variability!discrete-time} are:
@@ -1532,7 +1569,7 @@ \subsection{Discrete-Time Expressions}\label{discrete-time-expressions}
 \item
   Parameter expressions.
 \item
-  Discrete-time variables, see \cref{component-variability-prefixes-discrete-parameter-constant}.
+  Discrete-time variables, see \cref{component-variability}.
 \item
   Function calls where all input arguments of the function are discrete-time expressions.
 \item
@@ -1612,5 +1649,5 @@ \subsection{Continuous-Time and Non-Discrete-Time Expressions}\label{continuous-
 
 All expressions are continuous-time expressions\index{continuous-time!expression}\index{expression variability!continuous-time} including constant, parameter and discrete-time expressions.
 The term \firstuse{non-discrete-time expression}\index{expression variability!non-discrete-time} refers to expressions that are neither constant, parameter nor discrete-time expressions.
-For example, \lstinline!time! is a continuous-time built-in variable (see \cref{component-variability-prefixes-discrete-parameter-constant}) and \lstinline!time + 1! is a non-discrete-time expression.
+For example, \lstinline!time! is a continuous-time built-in variable (see \cref{component-variability}) and \lstinline!time + 1! is a non-discrete-time expression.
 Note that plain \lstinline!time! may, depending on context, refer to the continuous-time variable or the non-discrete-time expression.
diff --git a/chapters/overloaded.tex b/chapters/overloaded.tex
index 147997504..23a882338 100644
--- a/chapters/overloaded.tex
+++ b/chapters/overloaded.tex
@@ -46,7 +46,7 @@ \section{Overview of Overloaded Operators}\label{overview-of-overloaded-operator
 
 \section{Matching Function}\label{matching-function}
 
-All functions defined inside the \lstinline!operator! class must return one output (based on the restriction above), and may include functions with optional arguments, i.e.\ functions of the form
+All functions defined inside the \lstinline!operator! class must return one output (based on the restriction above), and may include functions with optional arguments, i.e., functions of the form
 \begin{lstlisting}[language=modelica]
 function f
   input $A_1$ $u_1$;
@@ -222,7 +222,7 @@ \section{Overloaded Binary Operations}\label{overloaded-binary-operations}
   Otherwise the expression is erroneous.
 \end{enumerate}
 
-For an element-wise operator, \lstinline!a .op b!, \cref{overloaded-binary-predefined,overloaded-binary-arrays,overloaded-binary-error} are used; e.g.\ the operator \lstinline!.+! will always be defined in terms of \lstinline!'+'!.
+For an element-wise operator, \lstinline!a .op b!, \cref{overloaded-binary-predefined,overloaded-binary-arrays,overloaded-binary-error} are used; e.g., the operator \lstinline!.+! will always be defined in terms of \lstinline!'+'!.
 
 Restrictions:
 \begin{itemize}
@@ -339,7 +339,7 @@ \section{Example of Overloading for Complex Numbers}\label{example-of-overloadin
   algorithm
     result := c1.re == c2.re and c1.im == c2.im;
     annotation(Inline = true);
- end '==';
+  end '==';
 
   encapsulated operator function 'String'
     import Complex;
diff --git a/chapters/packages.tex b/chapters/packages.tex
index d6c748ec7..03a516fb8 100644
--- a/chapters/packages.tex
+++ b/chapters/packages.tex
@@ -121,7 +121,7 @@ \subsection{Rules for Import-Clauses}\label{summary-of-rules-for-import-clauses}
   The \emph{order} of \lstinline!import!-clauses does not matter.
 \item
   One can only import \emph{from} packages, not from other kinds of classes.
-  Both packages and classes can be imported \emph{into} i.e., they may contain \lstinline!import!-clauses.
+  Both packages and classes can be imported \emph{into}, i.e., they may contain \lstinline!import!-clauses.
 \item
   An imported package or definition should always be referred to by its fully qualified name in the \lstinline!import!-clause.
 \item
@@ -144,7 +144,7 @@ \section{The Modelica Library Path -- MODELICAPATH}\label{the-modelica-library-p
 in general not advisable for a program installation to modify global
 environment variables. The version information for a library (as defined
 in \cref{annotations-for-version-handling}) may also be used during this search to search for a
-specific version of the library (e.g.\ if Modelica library version 2.2 is
+specific version of the library (e.g., if Modelica library version 2.2 is
 needed and the first directory in \lstinline!MODELICAPATH! contain Modelica library
 version 2.1, whereas the second directory contains Modelica version 2.2,
 then Modelica library version 2.2 is loaded from the second directory.).
@@ -172,7 +172,7 @@ \section{The Modelica Library Path -- MODELICAPATH}\label{the-modelica-library-p
   \label{fig:roots}
 \end{figure}
 
-Assume that we want to access the package \lstinline!MyLib.Pack2! in \cref{fig:roots} above, e.g.\ through an \lstinline!import!-clause \lstinline!import MyLib.Pack2;!.
+Assume that we want to access the package \lstinline!MyLib.Pack2! in \cref{fig:roots} above, e.g., through an \lstinline!import!-clause \lstinline!import MyLib.Pack2;!.
 During lookup we first try to find a package \lstinline!MyLib! corresponding to the first part of the name in the import-statement.
 It is not found in the top-level scope since it has not previously been loaded into the environment.
 
@@ -244,7 +244,7 @@ \subsection{Directory Hierarchy Mapping}\label{mapping-a-package-class-hierarchy
 
 \subsection{Single File Mapping}\label{mapping-a-package-class-hierarchy-into-a-single-file-nonstructured-entity}\label{single-file-mapping}
 
-When mapping a package or class-hierarchy to a file (e.g.\ the file \filename{A.mo}), that file shall only define a single class \lstinline!A! with a
+When mapping a package or class-hierarchy to a file (e.g., the file \filename{A.mo}), that file shall only define a single class \lstinline!A! with a
 name matching the name of the nonstructured entity. In a file hierarchy the files shall have the extension \filename{.mo}.
 
 A \filename{.mo} file defining more than one class cannot be part of the mapping
@@ -296,11 +296,11 @@ \section{External Resources}\label{external-resources}
 that precedes it. The first part of the path shall not be the name of a
 class in the package given by the authority.
 
-When Modelica packages are stored hierarchically in a file-system (i.e.\ package \lstinline!A! in a directory \filename{A} containing \filename{package.mo}) the resource
+When Modelica packages are stored hierarchically in a file-system (i.e., package \lstinline!A! in a directory \filename{A} containing \filename{package.mo}) the resource
 \filename{modelica://A/Resources/C.jpg} should be stored in the file \filename{A/Resources/C.jpg}, it is not recommend to use \filename{modelica://A.B/C.jpg} for referencing
 resources; it could be stored in the file \filename{A/B/C.jpg} -- which is counter-intuitive if \lstinline!A.B! is stored together with \lstinline!A!.  When Modelica packages
 are stored in other formats a similar mapping should be defined, such that a resource with a given path should be unique for any package name that precedes it.  The first
-part of the path shall not be the name of a class in the package given by the authority.  As above for \filename{Modelica 3.2.1/package.mo} i.e.\ resources starting from
+part of the path shall not be the name of a class in the package given by the authority.  As above for \filename{Modelica 3.2.1/package.mo}, i.e., resources starting from
 \filename{Modelica 3.2.1}, and \filename{modelica://Modelica.Mechanics/C.jpg} is \filename{Modelica 3.2.1/Mechanics/C.jpg} -- regardless of whether \lstinline!Modelica.Mechanics!
 is stored in \filename{Modelica 3.2.1/package.mo}, \filename{Modelica 3.2.1/Mechanics.mo}, or \filename{Modelica 3.2.1/Mechanics/package.mo}.
 
@@ -321,3 +321,187 @@ \section{External Resources}\label{external-resources}
 \filename{modelica://Modelica/Mechanics/C.jpg} is illegal.
 The references \filename{modelica://Modelica.Mechanics/C.jpg} and \filename{modelica://Modelica/C.jpg} must also refer to two distinct resources.
 \end{example}
+
+\section{Multilingual Descriptions}\label{multilingual-descriptions}\index{translation!multilingual libraries}
+
+\begin{nonnormative}
+Descriptive texts in a model or library are usually formulated in English.
+This section describes how a tool can present the library in another language.
+Translated Modelica text is provided by external files, so that no modification of the original Modelica text is required.
+\end{nonnormative}
+
+The texts in following Modelica constructs should be translated:
+\begin{itemize}
+\item description strings of component declarations and classes
+\item strings in the following annotations:
+\begin{itemize}
+\item \lstinline!Text.string!, \lstinline!Text.textString!
+\item \lstinline!missingInnerMessage!, \lstinline!obsolete!, \lstinline!unassignedMessage!
+\item \lstinline!Dialog.group!, \lstinline!Dialog.tab!
+\item
+  \lstinline!Dialog.loadSelector.caption!, \lstinline!Dialog.loadSelector.filter!,
+  \ifpdf\\\else\fi% Avoid comma ending up at beginning of wrapped line in PDF output.
+  \lstinline!Dialog.saveSelector.caption!, \lstinline!Dialog.saveSelector.filter!
+\item \lstinline!Documentation.info!, \lstinline!Documentation.revisions!
+\item \lstinline!Figure.title!, \lstinline!Figure.caption!, \lstinline!Figure.group!, \lstinline!Plot.title!, \lstinline!Axis.label!, \lstinline!Curve.legend!
+\item \lstinline!mustBeConnected!
+\end{itemize}
+\end{itemize}
+
+\begin{nonnormative}
+None of the translatable constructs can have any impact on simulation results.
+\end{nonnormative}
+
+Comments (delimited as well as rest-of-line) are not translated.
+Only constructs given entirely by one or more concatenated string literals are translated, using nothing but the operator \lstinline!+! for concatenation.
+In order to have parameter values as part of the texts the special substitution syntax is preferable (see \cref{text} and \cref{variable-replacements}), and translators need to be aware of these substrings in order to make good translations.
+
+\begin{example}
+Consider:
+\begin{lstlisting}[language=modelica]
+annotation($\ldots$, Text(string = "1st Frequency: %f1"),
+               Text(string = "2nd Frequency: " + String(w2 / (2 * pi))), $\ldots$);
+\end{lstlisting}
+In this example only \lstinline!"1st Frequency is %f1."! can be translated; the second \lstinline!Text.string! doesn't consist entirely of concatenated string literals, and is hence completely excluded from translation.
+\end{example}
+
+The files to support translation must be provided along with the library.
+They must be stored in the resources directory \filename{modelica://$\mathit{LibraryName}$/Resources/Language/}.
+
+Two kind of files in \textcite{GettextManual} format have to be provided:
+\begin{enumerate}
+\item Template file \filename{$\mathit{LibraryName}$.pot} (Portable Object Template), one file per library which is stored as the resource \filename{modelica://$\mathit{LibraryName}$/Resources/Language/$\mathit{LibraryName}$.pot}.
+It describes all translatable strings in the library, but does not contain any translations.
+The pattern \filename{$\mathit{LibraryName}$} denotes the toplevel class name of the library.
+\item One file for each supported language with the name \filename{$\mathit{LibraryName}$.$\mathit{language}$.po} (Portable Object), as the resource \filename{modelica://$\mathit{LibraryName}$/Resources/Language/$\mathit{LibraryName}$.$\mathit{language}$.po}.
+This file is a copy of the associated template file, but extended with the translations in the specified language.
+The pattern \filename{$\mathit{language}$} stands for the ISO 639-1 language code, e.g., \filename{de} or \filename{sv}.
+\end{enumerate}
+
+The detailed format of these files is described in \textcite{GettextManual}.
+Use of translation files in other formats (including the binary MO file format) is not standardized in Modelica.
+For Modelica translations, only the keywords \lstinline!msgctxt!, \lstinline!msgid! and \lstinline!msgstr! are used, meaning that a translation entry looks like this:
+\begin{lstlisting}
+#: $\mathit{filename}$:$\mathit{lineNumber}$
+#, no-c-format
+msgctxt $\mathit{messageContext}$
+msgid $\mathit{messageIdentifier}$
+msgstr $\mathit{messageTranslation}$
+\end{lstlisting}
+The restriction to a few keywords makes it easier for tools to support the format without relying on the implementation from \textcite{GettextManual}.
+
+The use of \lstinline!no-c-format! ensures that translation tools will not parse \lstinline!"%class"! as the format specifier \lstinline!%c! followed by \emph{lass}.
+
+\begin{nonnormative}
+In the remainder of this section, several facts about the gettext specification are interleaved non-normatively for easy access to some of the gettext basics.
+Always refer to the external gettext specification for full detail or in case of doubt.
+
+All text strings are in double quotes and encoded with UTF-8 characters.
+Comments start with an \lstinline!#! and are continued until the end of line.
+Spaces outside strings are ignored and used as separators.
+
+The files consist of a header and a body.
+The header is marked with an empty \lstinline!msgid! and looks like this:
+\begin{lstlisting}
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the PACKAGE package.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2019-03-15 10:52+0100\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"Language: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+\end{lstlisting}
+All general terms in the header should be replaced by specific information.
+
+Following the header, there is one translation entry for each string to be translated.
+It can start with an optional comment describing the location (file name and line number) of the text to translate.
+Multiple occurences of the same string can be listed here, separated by space.
+\end{nonnormative}
+
+The $\mathit{messageContext}$ following the keyword \lstinline!msgctxt! shall be the full name of the Modelica class (e.g., \lstinline!"Modelica.Blocks.Math.Sin"!) where the text appears.
+Short class definitions do not appear here.
+Texts in such classes belong to the enclosing full class definition.
+
+The text string which shall be translated is used as $\mathit{messageIdentifier}$ (following the \lstinline!msgid! keyword), and shall contain the original string from the Modelica code.
+% Describe down-quoting and concatenation of Modelica string literals.
+Note that if a \lstinline!msgid! string is given more than once in the same context, all occurrences are translated with the same (last) translation!
+
+\begin{nonnormative}
+The $\mathit{messageTranslation}$ (following the keyword \lstinline!msgstr!) is the translation of $\mathit{messageIdentifier}$ and is typically edited using special tools for translators.
+In the template file this string is empty by definition.
+If this is empty in a language specific file the $\mathit{messageIdentifier}$ may be used instead.
+\end{nonnormative}
+
+\begin{nonnormative}
+Since in Modelica control sequences also start with a backslash and another backslash is used to use sequences literally or to hide double quotes, no change is required here.
+But Modelica allows strings to go over more than one line, gettext does not.
+Therefore, line breaks in Modelica must be encoded with \lstinline!"\n"! for gettext.
+
+In order to avoid long lines in the translated strings (following \lstinline!msgid! or \lstinline!msgstr!), strings may be split into smaller parts given on consecutive lines.
+E.g., the Modelica description
+\begin{lstlisting}
+"A
+B\"C" + "D\nE"
+\end{lstlisting}
+evaluates to:\par
+\hspace{1em}\begin{minipage}{0.5\textwidth}
+A\\
+B"CD\\
+E
+\end{minipage}\par
+which in the translation entry looks like:
+\begin{lstlisting}
+msgid ""
+"A\n"
+"B\"CD\n"
+"E"
+\end{lstlisting}
+\end{nonnormative}
+
+\begin{example}
+Consider a simple sine-source:
+\begin{lstlisting}[language=modelica]
+within MyPackage.Sources;
+model Sine "Sine"
+  parameter Frequency f=2 "Frequency";
+  RealOutput y=sin(2*pi*f*time); // Relying on imported types
+  /* Could add details. Note that this is not translated */
+  annotation(Icon(graphics={Text(extent={{0,0},{40,40}},
+                        textString="Frequency: %f")}));
+end Sine;
+\end{lstlisting}
+The entries for translating this model into Swedish could look like this:
+\begin{lstlisting}
+#: MyPackage/Sources/package.mo:10126
+#, no-c-format
+msgctxt "MyPackage.Sources.Sine"
+msgid "Sine"
+msgstr "Sinus"
+#: MyPackage/Sources/package.mo:10127
+#, no-c-format
+msgctxt "MyPackage.Sources.Sine"
+msgid "Frequency"
+msgstr "Frekvens"
+#: MyPackage/Sources/package.mo:10131
+#, no-c-format
+msgctxt "MyPackage.Sources.Sine"
+msgid "Frequency: %f"
+msgstr "Frekvens: %f"
+\end{lstlisting}
+\end{example}
+
+\begin{nonnormative}
+To support the translation of these strings a number of free and commercial tools exist in context of GNU gettext.
+\end{nonnormative}
+
diff --git a/chapters/revisions.tex b/chapters/revisions.tex
index c5de539e6..0e80841e8 100644
--- a/chapters/revisions.tex
+++ b/chapters/revisions.tex
@@ -1,9 +1,280 @@
 \chapter{Modelica Revision History}\label{modelica-revision-history}
 
-This appendix describes the history of the Modelica Language Design, and
-its contributors. This appendix is just present for historic reasons and
-is not normative. The current version of this document is available from
-\url{https://www.modelica.org/documents}.
+This appendix describes the history of the Modelica Language Design, and its contributors.
+This appendix is just present for historic reasons and is not normative.
+The current version of this document is available from \url{https://modelica.org/documents}.
+
+\section{Modelica 3.6}\label{modelica-3-6}
+
+Modelica~3.6 will later be voted to be approved.
+The Modelica~3.6 specification was edited by Hans Olsson.
+
+\subsection{Main Changes in Modelica 3.6}\label{main-changes-in-modelica-3-6}
+
+The following Modelica Change Proposals are backward compatible extensions added in 3.6:
+\begin{itemize}
+\item Undefined modification (MCP-0009), \cref{removing-modifiers-break}.
+Ticket \specpull{3167}, and including changes in \specpull{2936} - and clarified in \specpull{3315}.
+\item Selective Model Extension (MCP-0032), \cref{selective-model-extension}.
+Ticket \specpull{3166}, and including changes in \specpull{2375}, \specpull{2422}, \specpull{2506}, \specpull{2507}, \specpull{2948}, and \specpull{3006}.
+\item Multilingual support of Modelica (MCP-0035), \cref{multilingual-descriptions}.
+Ticket \specpull{2956}, and including changes in \specpull{3126}, \specpull{3131}, and \specpull{3177}.
+\end{itemize}
+
+Additionally the \url{https://specification.modelica.org} landing page was updated with search functionality, \specpull{2911} correcting \specissue{2404}.
+
+Other issues resolved were:
+\begin{itemize}
+\item Deprecate String formatting of Real as Integer \specpull{3328}.
+\item Improve definition of exponentation \specpull{3285}.
+\item Clarified predefined type names, \specpull{3325} closing \specissue{2813}.
+\item Only restrict public connectors in blocks, \specpull{3318} closing \specissue{3309}.
+\item Improve iterator examples \specpull{3317}.
+\item Remove \lstinline!extends FilledShape! from Text-definitions, \specpull{3316} closes \specissue{2157}.
+\item Clarified each \specpull{3314} closing \specissue{3052}.
+\item Clarified lookup for choices \specpull{3307}.
+\item Constrain array assignment with implicit iterators \specpull{3306} closing \specissue{3250}.
+\item Refence connector balancing restriction \specpull{3305} closing \specissue{3260}.
+\item Correction: connect-clause was renamed to be connect-equation \specpull{3304}.
+\item Corrected example by adding type specifier \specpull{3303}.
+\item Don't say that String supports String, because it doesn't \specpull{3288} closing \specissue{3264}.
+\item Clarified that clock is only determined from equations \specpull{3283} closing \specissue{3265}.
+\item Clarify encapsulated short class definition \specpull{3282} closing \specissue{3270}.
+\item Correct broken link for a paper \specpull{3281}.
+\item Clarify the difference between when-equations and clocked when \specpull{3279} closing \specissue{3001}.
+\item Clean-up of terminology related to connection equations \specpull{3277} closing \specissue{3273}.
+\item Clarify String named argument combinations  \specpull{3262}.
+\item Specify that extent and preserveAspectRatio use the same logic \specpull{3253} closing \specissue{3219}.
+\item Don't give impression of undefined behavior being error \specpull{3248}.
+\item Clarify that a when-clause cannot activate multiple reinit for the same variable \specpull{3246}.
+\item More advanced elaboration for expandable connectors \specpull{3241} closing \specissue{3147}.
+\item Adjust non-normative description of smoothOrder \specpull{3237} closing \specissue{3200}.
+\item Clarify role of protected components passed to external functions \specpull{3236} closing \specissue{3188}.
+\item Add example for shiftSample \specpull{3233} closing \specissue{3040}.
+\item Add clocked discrete-time expressions to discrete-time, \specpull{3231} closing \specissue{3116}.
+\item Clarify record type compatible \specpull{3230} closing \specissue{3145}.
+\item Extend choicesAllMatching to records, \specpull{3229} closing \specissue{3210}.
+\item Remove zero start value and explain alternative, \specpull{3226}.
+\item Fix hard-coded cross references related to function application \specpull{3221}.
+\item Clarify elsewhen \specpull{3217} and \specpull{3228} closing \specissue{3216}.
+\item Correct invalid reference, \specpull{3218}.
+\item Also mention outputs when presenting list of inputs and outputs, \specpull{3215}.
+\item Clarify previous parameter expression \specpull{3214} closing \specissue{3074}.
+\item Annotation to limit number of connections \specpull{3212} and \specpull{3129} closing \specissue{3117}.
+\item Forbid combination of parameter and input, \specpull{3211} closing \specissue{3141}.
+\item Add directorySelector \specpull{3207}.
+\item Explain abs no event  clarification \specpull{3202}.
+\item Clarify that URIs shall also be converted \specpull{3201} closing \specissue{3199}.
+\item Clarify non-normative text for expandable connectors \specpull{3197} and \specpull{3195} closing \specissue{3194}.
+\item Remove arrayLayout since most tools have not implemented it, \specpull{3196} closing \specissue{3189}.
+\item Mandatory ignoring of trailing "1" in defaultComponentName, \specpull{3186} closing \specissue{3151}.
+\item Give a procedure for getting another name for components \specpull{3182} closing \specissue{3151}.
+\item Clarified that you cannot have equations or algorithm in types \specpull{3180} closing \specissue{3157}.
+\item Clarified "operator" \specpull{3179} closing \specissue{3171}.
+\item Clarify odd cases of IconMap and DiagramMap 'extent' \specpull{3160} closing \specissue{3150}.
+\item Illustrate potential implicit nature of discrete-time Real variable equations \specpull{3159}.
+\item Avoid need to define a term (simulator) \specpull{3152}.
+\item Define initialization, and simulation \specpull{3146}.
+\item Provide better alternative in Clock Example \specpull{3144} closing \specissue{3143}.
+\item Make it more clear that noEvent can make a difference inside functions \specpull{3142} closing \specissue{3136}.
+\item Variability rule for multiple return assignment (clarification) \specpull{3135}.
+\item Clarify DAE representation of discrete equations \specpull{3134} closing \specissue{3127}.
+\item Clarify nested records, \specpull{3130} closing \specissue{3128}.
+\item Do not require that all conditional connectors must be connected \specpull{3129} closing \specissue{3117}.
+\item A class is not a specialized class \specpull{3121}.
+\item Improve description of operator precedence \specpull{3119} closing \specissue{3110}.
+\item Clarify problem with non-clocked sample in clocked systems \specpull{3099}.
+\item Generalize calling functions through instances \specpull{3097} closing \specissue{3089}.
+\item Allow specifying both choices and choicesAllMatching (clarification) \specpull{3096} closing \specissue{3084}.
+\item Make conversion example clearer (clarification) \specpull{3095} closing \specissue{3081}.
+\item Allow "flow" for operator record which was defined \specpull{3094}.
+\item Simplify logic in Modelica code examples \specpull{3092} closing \specissue{3080}.
+\item Clarify synchronous code for odd cases \specpull{3090}.
+\item Minor corrections with empty arrays \specpull{3087}.
+\item Specify that all strings can be Unicode \specpull{3079} closing \specissue{3070}.
+\item Call the preferredView string the 'view' \specpull{3071}.
+\item Add icon to list of views \specpull{3067} closing \specissue{2987}.
+\item Clarify pure \specpull{3066} closing \specissue{2971}.
+\item Make GenerateEvents imply inlining \specpull{3065} closing \specissue{2986}.
+\item Clarify reinit \specpull{3063} closing \specissue{3001}.
+\item Clarify degree formatting \specpull{3048} closing \specissue{3020}.
+\item Allow derivatives to be referenced in figures \specpull{3046} closing \specissue{3044}.
+\item Make use of component variability when defining expression variability \specpull{3039}.
+\item Say we do 'cyber-physical systems', aligning with modelica.org \specpull{3037}.
+\item Clarify array range operator \specpull{3031} closing \specissue{3028}.
+\item Remove non-compensation sentence \specpull{3022}.
+\item Improve start-value priority by considering parameters \specpull{3019} closing \specissue{3008}.
+\item Clarify operator \specpull{3018} closing \specissue{3015}.
+\item Improved example for external function call \specpull{3010}.
+\item Turned equations into assignments in when-algorithm \specpull{2998}.
+\item Clearly define discrete time variable \specpull{2989}.
+\item Do not incorrectly use import name \specpull{2980} closing \specissue{2974}.
+\item Improve text for initialization \specpull{2961} closing \specissue{2947}.
+\item Clean up formulations and formatting related to 'is not provided' in 'Synchronous Language Elements' \specpull{2946}.
+\item Clarify that URI is absolute URI, might be changed later \specpull{2930} closing \specissue{2701}.
+\item Don't repeatedly explain that non-discrete time is continuous-time \specpull{2923} closing \specissue{2891}.
+\item Remove outdated reference of MSL for GenerateEvents annotation \specpull{2914}.
+\item Rephrase implied discrete-valued equation rule as non-normative observation \specpull{2907}.
+\item Improve description of string allocation functions \specpull{2903} closing \specissue{2858}.
+\item Don't present value of predefined type as having a name \specpull{2902} closing \specissue{2869}.
+\item Explain potential ambiguity of providing inverse functions \specpull{2901} closing \specissue{2866}.
+\item Constrain dimension of equalityConstraint \specpull{2898} closing \specissue{2886}.
+Updated to restore non-strict inequality for dimension of equalityConstraint \specpull{2909}.
+\item Fix description of "proposes to not inline" \specpull{2894}.
+\item Better variant of difference equation vs. algorithm \specpull{2890} closing \specissue{2814}.
+\item Clarify that Figure.caption and identifiers have an empty default \specpull{2889} closing \specissue{2851}.
+\item Clarified defaults for Dialog-annotation \specpull{2888} closing \specissue{2854}.
+\item Clarify discrete and remove odd statement about Pantelides \specpull{2887}.
+\item Clarified derivative example text \specpull{2881}.
+\item Clarify that continuous-time algorithm as well \specpull{2875} closing \specissue{2817}.
+\item Improved source directory example \specpull{2874} closing \specissue{2847}.
+\item Allow optional semicolon for conversions \specpull{2870} closing \specissue{2801}.
+\item Increase copyright year \specpull{2865}.
+\item Clarify noDerivative and zeroDerivative, \specpull{2864} closing \specissue{2840}.
+\item Add restriction on inverse and derivative \specpull{2863} closing \specissue{2837}.
+\item State that external objects must not depend on themselves, \specpull{2862} closing \specissue{2845}.
+\item Clean up example "Variables with array dimensions" \specpull{2857} closing \specissue{2855}.
+\item Don't call the Dialog a "menu" \specpull{2849}.
+\item Stop saying that 'promote' isn't a Modelica function \specpull{2844} closing \specissue{2843}.
+\item Use macro and proper reference \specpull{2834}.
+\item Clean up description of the Dialog annotation \specpull{2819} closing \specissue{2476}.
+\item Remove incorrect string quoting of '+' for string concatenation \specpull{2810}.
+\item Remove comment with definition of 'partial flattening' from old glossary \specpull{2807} closing \specissue{2787}.
+\item Switch from 3.5 to 3.6-dev; \specpull{2791} and \specpull{2794}.
+\item Better integration of terms 'instantaneous equation/statement' \specpull{2788}.
+\item Say 'variable value' instead of 'value-attribute' \specpull{2786}.
+\item Treat 'connect' like the keyword it is in listings \specpull{2785}.
+\item Improvements in the style of presentations including correcting typos:
+\begin{itemize}
+\item Update bibliography item \specpull{3338} closing \specissue{3337}.
+\item Fix minor typo, \specpull{3333}.
+\item Fix indentation error in listing, \specpull{3331}.
+\item Consistent punctuation for "e.g." and "i.e." \specpull{3329} closing \specissue{3235}.
+\item Simplified presentation of Transformation-annotation, \specpull{3326} closing \specissue{3275}.
+\item Explained quote around code fragments, \specpull{3324} closing \specissue{3191}.
+\item Clean up absoluteValue formatting \specpull{3301}.
+\item Split the restrictions for when-equations into two lists, \specpull{3292}.
+\item Add missing "if" in "if and only they" \specpull{3289}.
+\item Fix formatting of 'if-clause' \specpull{3276}.
+\item Fix grammar 'is' -> 'are' \specpull{3272} closing \specissue{3271}.
+\item Add 'cat' to document index  \specpull{3268}.
+\item Fix missing formatting of "T" \specpull{3267}.
+\item Work-around for table issue in LaTeXML \specpull{3208} and \specpull{3205} closing \specissue{3156}.
+\item Add 'time' to document index \specpull{3203}.
+\item Remove spurious semi-colons \specpull{3193} closing \specissue{3192}.
+\item Clarified description of BaseProperties in example \specpull{3190}.
+\item Avoid bad leading white-space inside strings in StateSelect definition \specpull{3185}.
+\item Fix false indention in code listings \specpull{3181} and \specpull{3183}.
+\item Fix typo 'GraphicsItem' -> 'GraphicItem' \specpull{3176}.
+\item Correctly use may be \specpull{3174} closing \specissue{3165}.
+\item Minor cleanup for for-equation listings \specpull{3170}.
+\item Library annotation supports arrays, not tuples \specpull{3132}.
+\item Remove trailing blank \specpull{3124}.
+\item Add trailing semicolon \specpull{3120}.
+\item Clean up quadrature listings \specpull{3114}.
+\item Changed y into x in spatialDistribution() definitions  clarification \specpull{3113}.
+\item Add missing closing '!' in preferredView specification \specpull{3112}.
+\item Fix indentation of listings related to versionDate and friends \specpull{3105}.
+\item Version annotation indent \specpull{3104}.
+\item Fix indentation of Ellipse pseudo-code record definition \specpull{3085}.
+\item Fix oversize listing lines \specpull{3082}.
+\item Make first part of section name matter \specpull{3073} and shorten in \specpull{3100}.
+\item Better definition of comments \specpull{3064} closing \specissue{2992}.
+\item Fix minor issues in chapter 'Connectors and Connections' \specpull{3061}.
+\item Remove incorrect escaping of '\&' in bibliography 'url' entry \specpull{3059} closing \specissue{3056}.
+\item More stable links for openprod \specpull{3058} closing \specissue{3055}.
+\item Remove leading www from web-links \specpull{3057} closing \specissue{3054}.
+\item Remove excessive indexing of 'inverse' annotation \specpull{3050} closing \specissue{3047}.
+\item Improve descriptions of notation \specpull{3045} closing \specissue{3044}.
+\item Tighten connection between \firstuse and document index \specpull{3043} correcting  \specissue{3041}.
+\item Fix typos in Section 5.4 \specpull{3032} and \specpull{3036}.
+\item Ensure that Modelica code in HTML is teletype! \specpull{3034}.
+\item Sentence-based line breaking in operatorsandexpressions.tex \specpull{3030}.
+\item Remove unused parameter 'p' in example for 'smooth' \specpull{3029}.
+\item Fix problems with 'parenthesis' in the singular \specpull{3027} closing \specissue{3026}.
+\item Fix typo for homotopy \specpull{3016}.
+\item Clean up chapter 'Unit Expressions' \specpull{3013}.
+\item Cleanup file hierarchy listings \specpull{3011}.
+\item Fix year in date reference \specpull{3002}.
+\item Fix formatting of 'when', 'elsewhen', and 'when initial()' \specpull{3000}.
+\item Consistently quote in grammar (and remove one spurious ;) \specpull{2990} closing \specissue{2988}.
+\item Small cleanup of scoping chapter \specpull{2982}.
+\item Fix typo: 'subsample' -> 'subSample' \specpull{2979}.
+\item Start bullet item with upper case letter \specpull{2976}.
+\item Cross reference multiple extends rule, and related cleanup \specpull{2978}.
+\item Mostly trivial clean up related to equations and statements \specpull{2975}.
+\item Fix typo in specification of 'delay' \specpull{2973}.
+\item Align keywords for 'grammar' with keywords for 'modelica' \specpull{2972}.
+\item Remove copy-paste from unknown source \specpull{2970} closing \specissue{2968}.
+\item Correct double for (introduced in \specpull{2916}) \specpull{2969} closing \specissue{2966}.
+\item Fix moist air2 and apply the style guide to the next paragraph \specpull{2964} closing \specissue{2963}.
+\item Move and add reference to rule about constants having declaration equation \specpull{2960} closing \specissue{2945}.
+\item Add style guide section on inline code at beginning of sentence \specpull{2959} closing \specissue{2943}.
+\item Gather annotations for functions \specpull{2922} closing \specissue{2895}.
+\item Apply style guide \specpull{2916} closing \specissue{2713}.
+\item Add blank after extends \specpull{2913}.
+\item Cleanup of "Matching Function" \specpull{2910}.
+\item Fix line breaks in connector examples \specpull{2906} and \specpull{2905}.
+\item Fix bad backslash in C-code \specpull{2897}.
+\item Add specification document style guide \specpull{2884} closing \specissue{2713}.
+\item Styling cleanup for 'derivative' annotation \specpull{2883}.
+\item Fix white-space errors in recently introduced example on derivative \specpull{2880}.
+\item Break down first items describing ExternalObject \specpull{2879}.
+\item Be more consistent with Modelica.StateGraph \specpull{2876} closing \specissue{2839}.
+\item Revert "Use angle brackets for '<describing text>' in listings \specpull{2868} closing \specissue{2867}.
+\item Add missing plural 's' \specpull{2860}.
+\item Minor formatting cleanup related to colon (:) dimensions \specpull{2856}.
+\item More systematic use of \lstinline for figure annotations Axis and Curve \specpull{2850}.
+\item Cleanup formatting related to lexical conventions \specpull{2846}.
+\item Minor cleanup of inline code and math for Derivative annotation \specpull{2836}.
+\item Align duplicated parts of lexing rules \specpull{2831}.
+\item Protect space after \LaTeX{} \specpull{2829}.
+\item Typo corrections from revision 3.5 \specpull{2828}.
+\item Clean up ellipsis and angle brackets in listings \specpull{2812}.
+\item Avoid overlong lines \specpull{2809} closes \specissue{2796}.
+\item Add 'MODELICAPATH' to the index \specpull{2808}.
+\item Fix typo in 'bibliograph\emph{y}' \specpull{2803}.
+\item Use colon instead of dash when attaching 'th' to ordinals \specpull{2793}.
+\item Use comments instead of text escape in array indexing listing \specpull{2789}.
+\item Fix issues with C listings \specpull{2784} (already added in 3.5).
+\item Don't treat 'nondiscrete' as keyword in listings \specpull{2783}.
+\end{itemize}
+\item Improvements in build system and \LaTeX{} (including workarounds):
+\begin{itemize}
+\item Only load cmap.sty when building PDF \specpull{3323}.
+\item Add globs to cleaning targets \specpull{3319}.
+\item Comments regarding recently fixed LaTeXML issues \specpull{3308}.
+\item Do not remove curl from the docker image \specpull{3299}.
+\item Support search and copying of ligatures \specpull{3296}, \specpull{3294} closing \specissue{3286}.
+\item Update to texlive 2022 \specpull{3148}.
+\item Use the listings.sty option upquote=true  LaTeXIssue with the LaTeX code \specpull{3123} closing \specissue{3122}.
+\item Address fancyhdr warning about too small 'headheight' \specpull{3086}.
+\item Update status regarding LaTeXML issue 1719 \specpull{3083}.
+\item Name the HTML entry page 'index.html' \specpull{3077} closing \specissue{3076}.
+\item Increase sizes a bit, and use "smallifpdf" for comments \specpull{3072}.
+\item Tweak CSS for :target:before \specpull{3069} closing \specissue{2967}.
+\item Work around LaTeXML problem with line breaks around 'tabbing' environment \specpull{3042} closing \specissue{3009}.
+\item Add space for LaTeXML to fix formatting of -2 \specpull{3025} and \specpull{3033} closing \specissue{3024}.
+\item (Continuous integration) Set a username before git commit \specpull{3021}.
+\item Avoid just a '0' in lstinline when generating HTML \specpull{2993} closing \specissue{2991}.
+\item Update comments about LaTeXML issues that are now fixed on 'master' \specpull{2983}.
+\item (Continuous integration) Workaround for the markdown image not having ssh-agent \specpull{2939}.
+\item Make the menu hover work on iOS Safari \specpull{2934}.
+\item Do not use block links in the page header \specpull{2933}.
+\item Add a meta viewport tag to counter small text \specpull{2932}.
+\item Push builds to github-pages instead of SSH upload \specpull{2925}.
+\item Add newtxtt.sty to LaTeXML continuous integration builds \specpull{2908}.
+\item Add comments with TODOs after LaTeXML issue is fixed \specpull{2882}.
+\item Added logo in ReadMe.md \specpull{2877}, \specpull{2873}, and \specpull{2833}.
+\item Avoid current HTML jump target being hidden behind page header \specpull{2841}.
+\item Remove HTML footer links to bibliography and index \specpull{2832}.
+\item Remove Travis CI badge from README.md \specpull{2821}.
+\item Add keywords to generated PDF, \specpull{2802}.
+\item Update comment regarding LaTeXML issue 1400 (now fixed) \specpull{2800}.
+\item Improve navbar on top page \specpull{2799}.
+\item Pass option 'pdfusetitle' to hyperref.sty \specpull{2797} closing \specissue{2795}.
+\end{itemize}
+\end{itemize}
 
 \section{Modelica 3.5}\label{modelica-3-5}
 
@@ -295,7 +566,7 @@ \subsection{Main Changes in Modelica 3.5}\label{main-changes-in-modelica-3-5}
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2676}{\#2676}.
 \item Made when-descriptions more similar, \cref{restrictions-on-where-a-when-equation-may-occur} and \cref{restrictions-on-equations-within-when-equations}.
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2635}{\#2635}.
-\item Make assertion level a structural parameter, \cref{assert}.
+\item Make assertion level an evaluable parameter, \cref{assert}.
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2642}{\#2642}.
 \item Deprecate byte order mark, \cref{mapping-a-package-class-hierarchy-into-a-directory-hierarchy-structured-entity}.
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2675}{\#2675}.
@@ -323,7 +594,7 @@ \subsection{Main Changes in Modelica 3.5}\label{main-changes-in-modelica-3-5}
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2552}{\#2552}.
 \item Clarify pre for arrays, \cref{event-related-operators-with-function-syntax}.
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2556}{\#2566}.
-\item Clarify variability guarantee, \cref{component-variability-prefixes-discrete-parameter-constant}.
+\item Clarify variability guarantee, \cref{component-variability}.
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2553}{\#2553}.
 \item Corrected errors in example of over-determined connectors for power system, \cref{an-overdetermined-connector-for-power-systems}.
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2564}{\#2564}.
@@ -349,7 +620,7 @@ \subsection{Main Changes in Modelica 3.5}\label{main-changes-in-modelica-3-5}
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2295}{\#2295}.
 \item Clarified when initial() for algorithms, \cref{initialization-initial-equation-and-initial-algorithm}.
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2436}{\#2436}.
-\item Clarify differentiability of expressions, \cref{component-variability-prefixes-discrete-parameter-constant}.
+\item Clarify differentiability of expressions, \cref{component-variability}.
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2464}{\#2464}.
 \item Clarified standard type coercion, \cref{standard-type-coercion}.
 Ticket \href{https://github.com/modelica/ModelicaSpecification/issues/2326}{\#2326}.
@@ -1559,7 +1830,7 @@ \subsection{Main Changes in Modelica 3.2}\label{main-changes-in-modelica-3-2}
 \item
   Constants can once again be modified unless declared final -- as this is already used in packages.  (See \cref{constant-expressions}).
 \item
-  Global name lookup has been introduced (e.g.
+  Global name lookup has been introduced (e.g.,
   \lstinline!.Modelica.Constants.pi!), see \cref{global-name-lookup}.
 \item
   New C functions \lstinline!ModelicaVFormatMessage! and \lstinline!ModelicaVFormatError!, to
@@ -2196,7 +2467,7 @@ \subsection{Main Changes in Modelica 3.0}\label{main-changes-in-modelica-3-0}
   New attribute \lstinline!Smooth = enumeration(None, Bezier)! for graphical objects
   and connection lines (Bezier defines a Bezier spline).\\
   New attribute \lstinline!visible! in \lstinline!record Placement! allows making a graphical
-  annotation invisible (e.g.\ after inheritance).\\
+  annotation invisible (e.g., after inheritance).\\
   New attributes \lstinline!startAngle!, \lstinline!endAngle! in record ellipse to define part
   of an ellipse.\\
   New layer specific annotations \lstinline!IconMap! and \lstinline!DiagramMap! for \lstinline!extends!.\\
@@ -2393,7 +2664,7 @@ \subsection{Main Changes in Modelica 2.1}\label{main-changes-in-modelica-2-1}
   base constraining type automatically to modifications.
 \item
   Enhanced redeclaration as needed, e.g., in the Modelica.Media library
-  under development (e.g.\ \lstinline!redeclare model name! or \lstinline!model extends name (<modifications>)!).
+  under development (e.g., \lstinline!redeclare model name! or \lstinline!model extends name (<modifications>)!).
 \item
   Handling of overdetermined connectors (needed, e.g., for multi-body
   systems and electrical power systems) including the new built-in
@@ -2415,7 +2686,7 @@ \subsection{Main Changes in Modelica 2.1}\label{main-changes-in-modelica-2-1}
   in a mathematically clean way).
 \item
   More general identifiers by having any character in single quotes,
-  e.g.\ \lstinline!'+'! or '123.456\#1' are valid identifiers. \lstinline!'x'! and \lstinline!x! are
+  e.g., \lstinline!'+'! or '123.456\#1' are valid identifiers. \lstinline!'x'! and \lstinline!x! are
   different identifiers. This is useful for a direct mapping of product
   identifiers to model names and for having the usual symbols for
   digital electrical signals as enumerations (such as \lstinline!'+'!, \lstinline!'-'!, \lstinline!'0'!,
@@ -2654,7 +2925,7 @@ \subsection{Main Changes in Modelica 1.4}\label{main-changes-in-modelica-1-4}
   automatically generated when the result value of one of these operator
   changes discontinuously.
 \item
-  Quantity attribute also for base types \lstinline!Boolean!, \lstinline!Integer!, \lstinline!String! (and not only for \lstinline!Real!), in order to allow abstracted variables to refer to physical quantities (e.g.\ \lstinline!Boolean i(quantity="Current")! is true if current is flowing and is false if no current is flowing).
+  Quantity attribute also for base types \lstinline!Boolean!, \lstinline!Integer!, \lstinline!String! (and not only for \lstinline!Real!), in order to allow abstracted variables to refer to physical quantities (e.g., \lstinline!Boolean i(quantity="Current")! is true if current is flowing and is false if no current is flowing).
 \item
   \lstinline!final! keyword also allowed in declaration, to prevent modification.
   Example:
@@ -2671,7 +2942,7 @@ \subsection{Main Changes in Modelica 1.4}\label{main-changes-in-modelica-1-4}
 \item
   Several minor enhancements, such as usage of dot-notation in
   modifications\\
-  (e.g.: \lstinline!A x(B.C=1, B.D=2)! is the same as \lstinline!A x(B(C=1, D=2))!).
+  (e.g., \lstinline!A x(B.C=1, B.D=2)! is the same as \lstinline!A x(B(C=1, D=2))!).
 \item
   Internally restructured specification.
 \end{itemize}
diff --git a/chapters/scoping.tex b/chapters/scoping.tex
index 2d2ca2c68..0af8f3c24 100644
--- a/chapters/scoping.tex
+++ b/chapters/scoping.tex
@@ -79,7 +79,7 @@ \subsection{Simple Name Lookup}\label{simple-name-lookup}
   It is an error if this step produces matches from several unqualified imports.
 \end{itemize}
 
-The \lstinline!import!-clauses defined in inherited classes are ignored for the lookup, i.e.\ \lstinline!import!-clauses are not inherited.
+The \lstinline!import!-clauses defined in inherited classes are ignored for the lookup, i.e., \lstinline!import!-clauses are not inherited.
 
 
 \subsection{Composite Name Lookup}\label{composite-name-lookup}
@@ -96,9 +96,14 @@ \subsection{Composite Name Lookup}\label{composite-name-lookup}
   All identifiers of the rest of the name (e.g., \lstinline!B! and \lstinline!B.C!) must be classes.
   That is, the composite name is comprised of one or more component names (optionally with indexing), followed by one or more class names.
 \item
-  If the identifier denotes a class, that class is temporarily flattened (as if instantiating a component without modifiers of this class, see \cref{modification-environment}) and using the enclosing classes of the denoted class.
+  If the identifier denotes a class, that class is temporarily flattened (as if instantiating a component without modifiers of this class, see \cref{modification-environment} and using the enclosing classes of the denoted class).
   The rest of the name (e.g., \lstinline!B! or \lstinline!B.C!) is looked up among the declared named elements of the temporary flattened class.
-  If the class does not satisfy the requirements for a package, the lookup is restricted to encapsulated\indexinline{encapsulated} elements only.
+  The lookup will only find the element (assuming it exists) in the following cases:
+  \begin{itemize}
+  \item If the class is declared as \lstinline!package! or \lstinline!operator! (but not \lstinline!operator record! or \lstinline!operator function!) all elements can be found.
+  \item An element can be found if it is declared as \lstinline!encapsulated!\indexinline{encapsulated}.
+  \item A deprecated case is that if the class satisfies the requirements for a \lstinline!package! (without being declared as such), it is still treated as a \lstinline!package!.
+  \end{itemize}
   The class we look inside shall not be partial in a simulation model.
 \end{itemize}
 
@@ -123,10 +128,16 @@ \subsection{Composite Name Lookup}\label{composite-name-lookup}
 \end{lstlisting}
 \end{example}
 
+\begin{nonnormative}
+Note that an \lstinline!operator! class may only contain declarations of functions and thus fulfills the requirements for a package (see \cref{specialized-classes}).
+In practice, the non-deprecated rules imply that we can call \lstinline!Complex.'-'.negate! and \lstinline!Complex.'+'! for the example in \cref{example-of-overloading-for-complex-numbers}.
+This requires that \lstinline!operator '-'! and \lstinline!operator function '+'! are declared as \lstinline!encapsulated! as in the example.
+\end{nonnormative}
+
 
 \subsection{Global Name Lookup}\label{global-name-lookup}
 
-For a name starting with dot, e.g.: \lstinline!.A! (or \lstinline!.A.B!, \lstinline!.A.B.C! etc.) lookup is performed as follows:
+For a name starting with dot, e.g., \lstinline!.A! (or \lstinline!.A.B!, \lstinline!.A.B.C! etc.) lookup is performed as follows:
 \begin{itemize}
 \item
   The first identifier (\lstinline!A!) is looked up in the global scope.
@@ -135,7 +146,7 @@ \subsection{Global Name Lookup}\label{global-name-lookup}
 \item
   If the name is simple then the class \lstinline!A! is the result of lookup.
 \item
-  If the name is a composite name then the class \lstinline!A! is temporarily flattened with an empty environment (i.e.\ no modifiers, see \cref{modification-environment}) and using the enclosing classes of the denoted class.
+  If the name is a composite name then the class \lstinline!A! is temporarily flattened with an empty environment (i.e., no modifiers, see \cref{modification-environment} and using the enclosing classes of the denoted class).
   The rest of the name (e.g., \lstinline!B! or \lstinline!B.C!) is looked up among the declared named elements of the temporary flattened class.
   If the class does not satisfy the requirements for a package, the lookup is restricted to encapsulated elements only.
   The class we look inside shall not be partial.
@@ -168,7 +179,7 @@ \section{Inner Declarations - Instance Hierarchy Name Lookup}\label{instance-hie
 \item
   If there is one (or more) \lstinline!outer! declarations of a partial class it is an error.
 \item
-  In other cases, i.e.\ if a unique non-partial class is used for all \lstinline!outer! declarations of the same name lacking a matching inner declaration, then an \lstinline!inner! declaration of that class is automatically added at the top of the model and a diagnostic is given.
+  In other cases, i.e., if a unique non-partial class is used for all \lstinline!outer! declarations of the same name lacking a matching inner declaration, then an \lstinline!inner! declaration of that class is automatically added at the top of the model and a diagnostic is given.
 \item
   The annotations defined in \cref{annotations-for-the-graphical-user-interface} does not affect this process, other than that:
   \begin{itemize}
@@ -367,7 +378,7 @@ \subsection{Instantiation}\label{instantiation}
 
 \subsubsection{The Class Tree}\label{the-class-tree}
 
-All necessary libraries including the model which is to be instantiated are loaded from e.g.\ file system and form a so called \firstuse{class tree}.
+All necessary libraries including the model which is to be instantiated are loaded (e.g., from a file system) and form a so called \firstuse{class tree}.
 This tree represents the syntactic information from the class definitions.
 It contains also all modifications at their original locations in syntactic form.
 The builtin classes are put into the unnamed root of the class tree.
@@ -440,7 +451,7 @@ \subsubsection{Steps of Instantiation}\label{steps-of-instantiation}
 
 \paragraph*{The element itself}\label{the-element-itself}
 
-A \firstuse{partially instantiated} class or component is an element that is ready to be instantiated; a partially instantiated element (i.e.\ class or component) is comprised of a reference to the original element (from the class tree) and the modifiers for that element (including a possible redeclaration).
+A \firstuse{partially instantiated} class or component is an element that is ready to be instantiated; a partially instantiated element (i.e., class or component) is comprised of a reference to the original element (from the class tree) and the modifiers for that element (including a possible redeclaration).
 
 The possible redeclaration of the element itself takes effect.
 
@@ -458,7 +469,7 @@ \subsubsection{Steps of Instantiation}\label{steps-of-instantiation}
 Equations, algorithms, and annotations of the class and the component declaration are copied to the instance without merging.
 
 \begin{nonnormative}
-The annotations can be relevant for simulations, e.g.\ annotations for symbolic processing (\cref{modelica:Evaluate}), simulation experiments (\cref{modelica:experiment}) or functions (\cref{derivatives-and-inverses-of-functions} and \cref{external-function-interface}).
+The annotations can be relevant for simulations, e.g., annotations for symbolic processing (\cref{modelica:Evaluate}), simulation experiments (\cref{modelica:experiment}) or functions (\cref{derivatives-and-inverses-of-functions} and \cref{external-function-interface}).
 \end{nonnormative}
 
 The \lstinline!extends!-clauses are not looked up, but empty \lstinline!extends!-clause nodes are created and inserted into the current instance (to be able to preserve the declaration order of components).
@@ -576,7 +587,7 @@ \subsection{Generation of the Flat Equation System}\label{generation-of-the-flat
 
 \begin{nonnormative}
 This identifier is normally constructed from the names of the instances along a path in the instance tree (and omitting the unnamed nodes of \lstinline!extends!-clauses), separated by dots.
-Either the referenced instance belongs to the model to be simulated the path starts at the model itself, or if not, it starts at the unnamed root of the instance tree, e.g.\ in case of a constant in a package.
+Either the referenced instance belongs to the model to be simulated the path starts at the model itself, or if not, it starts at the unnamed root of the instance tree, e.g., in case of a constant in a package.
 \end{nonnormative}
 
 \begin{nonnormative}
@@ -613,7 +624,7 @@ \subsection{Generation of the Flat Equation System}\label{generation-of-the-flat
     If it is of simple type (\lstinline!Boolean!, \lstinline!Integer!, enumeration, \lstinline!Real!, \lstinline!String!, \lstinline!Clock!, \lstinline!ExternalObject!):
     \begin{itemize}
     \item
-      In the modifications of \emph{non-value} attributes, e.g.\ \lstinline!start!, \lstinline!fixed! etc.\ references are resolved using the instance scope of the modification.
+      In the modifications of \emph{non-value} attributes, e.g., \lstinline!start!, \lstinline!fixed! etc.\ references are resolved using the instance scope of the modification.
       An equation is formed from a reference to the name of the instance appended by a dot and the attribute name and the resolved modification value of the instance, and included into the equation system.
     \end{itemize}
   \item
@@ -634,11 +645,11 @@ \subsection{Generation of the Flat Equation System}\label{generation-of-the-flat
 \item
   Conditional components with false condition are removed afterwards and they are not part of the simulation model.
   \begin{nonnormative}
-  Thus e.g.\ parameters don't need values in them.
+  Thus, e.g., parameters don't need values in them.
   However, type-error can be detected.
   \end{nonnormative}
 \item
-  Each reference is checked, whether it is a valid reference, e.g.\ the referenced object belongs to or is an instance, where all existing conditional declaration expressions evaluate to true or it is a constant in a package.
+  Each reference is checked, whether it is a valid reference, e.g., the referenced object belongs to or is an instance, where all existing conditional declaration expressions evaluate to true or it is a constant in a package.
   \begin{nonnormative}
   Conditional components can be used in \lstinline!connect!-equations, and if the component is conditionally disabled the \lstinline!connect!-equation is removed.
   \end{nonnormative}
@@ -646,8 +657,8 @@ \subsection{Generation of the Flat Equation System}\label{generation-of-the-flat
 
 This leads to a flattened equation system, except for \lstinline!connect!- and \lstinline!transition!-equations.
 These have to be transformed as described in \cref{connectors-and-connections} and \cref{state-machines}.
-This may lead to further changes in the instance tree (e.g.\ from expandable connectors (\cref{expandable-connectors})) and additional equations in the flattened equation system (e.g.\ connection equations (\cref{generation-of-connection-equations}), generated equations for state machine semantics (\cref{semantics-summary})).
+This may lead to further changes in the instance tree (e.g., from expandable connectors (\cref{expandable-connectors})) and additional equations in the flattened equation system (e.g., connection equations (\cref{generation-of-connection-equations}), generated equations for state machine semantics (\cref{semantics-summary})).
 
 \begin{nonnormative}
-After flattening, the resulting equation system is self contained and covers all information needed to transform it to a simulatable model, but the class and instance trees are still needed: in the transformation process, there might be the need to instantiate further functions, e.g.\ from \lstinline!derivative! annotation or from \lstinline!inverse! annotation etc., on demand.
+After flattening, the resulting equation system is self contained and covers all information needed to transform it to a simulatable model, but the class and instance trees are still needed: in the transformation process, there might be the need to instantiate further functions, e.g., from \lstinline!derivative! annotation or from \lstinline!inverse! annotation etc., on demand.
 \end{nonnormative}
diff --git a/chapters/statemachines.tex b/chapters/statemachines.tex
index 7aa2aa919..08a3f0e38 100644
--- a/chapters/statemachines.tex
+++ b/chapters/statemachines.tex
@@ -90,8 +90,8 @@ \section{Transitions}\label{transitions}
 The transition fires when $\mathit{condition} = \text{\lstinline!true!}$ if $\mathit{imm} = \text{\lstinline!true!}$ (this is called an \firstuse{immediate transition}\index{transition!immediate}) or \lstinline!previous($\mathit{condition}$)! when $\mathit{imm} = \text{\lstinline!false!}$ (this is called a \firstuse{delayed transition}\index{transition!delayed}).
 Argument \lstinline!priority! defines the priority of firing when several transitions could fire.
 In this case the transition with the smallest value of \lstinline!priority! fires.
-It is required that $\mathit{prio} \geq 1$ and that for all transitions from the same state, the priorities are different. If $\mathit{reset} = \text{\lstinline!true!}$, the states of the target state are reinitialized, i.e.\ state machines are restarted in initial state and state variables are reset to their start values.
-If $\mathit{synch} = \text{\lstinline!true!}$, any transition is disabled until all state machines of the from-state have reached final states, i.e.\ states without outgoing transitions.
+It is required that $\mathit{prio} \geq 1$ and that for all transitions from the same state, the priorities are different. If $\mathit{reset} = \text{\lstinline!true!}$, the states of the target state are reinitialized, i.e., state machines are restarted in initial state and state variables are reset to their start values.
+If $\mathit{synch} = \text{\lstinline!true!}$, any transition is disabled until all state machines of the from-state have reached final states, i.e., states without outgoing transitions.
 For the precise details about firing a transition, see \cref{state-machine-semantics}.
 \end{semantics}
 \end{operatordefinition}
@@ -121,7 +121,7 @@ \section{Transitions}\label{transitions}
 ticksInState()
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-Returns the number of ticks of the clock of the state machine for which the currently active state has maintained its active state without interruption, i.e.\ without local or hierarchical transitions from this state.  In the case of a self-transition to the currently active state or to an active enclosing state, the number is reset to one.
+Returns the number of ticks of the clock of the state machine for which the currently active state has maintained its active state without interruption, i.e., without local or hierarchical transitions from this state.  In the case of a self-transition to the currently active state or to an active enclosing state, the number is reset to one.
 
 This function can only be used in state machines.
 \end{semantics}
@@ -132,7 +132,7 @@ \section{Transitions}\label{transitions}
 timeInState()
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-Returns the time duration as \lstinline!Real! in {[}s{]} for which the currently active state has maintained its active state without interruption, i.e.\ without local or hierarchical transitions from this state. In the case of a self-transition to the currently active state or to an active enclosing state, the time is reset to zero.
+Returns the time duration as \lstinline!Real! in {[}s{]} for which the currently active state has maintained its active state without interruption, i.e., without local or hierarchical transitions from this state. In the case of a self-transition to the currently active state or to an active enclosing state, the time is reset to zero.
 
 This function can only be used in state machines.
 \end{semantics}
@@ -277,7 +277,7 @@ \subsection{State Activation}\label{state-activation}
 \end{lstlisting}
 
 In a similar way, the \lstinline!Integer delayed! is calculated as the index for a
-potentially delayed transition, i.e.\ a transition taking place at the
+potentially delayed transition, i.e., a transition taking place at the
 next clock tick. In this case the from-state needs to be equal to
 \lstinline!nextState!:
 \begin{lstlisting}[language=modelica]
@@ -301,7 +301,7 @@ \subsection{State Activation}\label{state-activation}
     previous(nextState);
 \end{lstlisting}
 In order to define synchronize transitions, each state machine must
-determine which are the final states, i.e.\ states without
+determine which are the final states, i.e., states without
 from-transitions and to determine if the state machine is in a final
 state currently:
 \begin{lstlisting}[language=modelica]
@@ -467,7 +467,7 @@ \subsection{Example}\label{example}
 \item
   \lstinline!state1! is a meta state with two parallel state machines in it.
 \item
-  \lstinline!stateA! declares \lstinline!v! as \lstinline!outer output!. \lstinline!state1! is on an intermediate level and declares \lstinline!v! as \lstinline!inner outer output!, i.e.\ matches lower level \lstinline!outer v! by being \lstinline!inner! and also matches higher level \lstinline!inner v! by being \lstinline!outer!.
+  \lstinline!stateA! declares \lstinline!v! as \lstinline!outer output!. \lstinline!state1! is on an intermediate level and declares \lstinline!v! as \lstinline!inner outer output!, i.e., matches lower level \lstinline!outer v! by being \lstinline!inner! and also matches higher level \lstinline!inner v! by being \lstinline!outer!.
   The top level declares \lstinline!v! as \lstinline!inner! and gives the start value.
 \item
   \lstinline!count! is defined with a start value in \lstinline!state1!. It is reset when
diff --git a/chapters/statements.tex b/chapters/statements.tex
index 7b457173e..5ce0304d4 100644
--- a/chapters/statements.tex
+++ b/chapters/statements.tex
@@ -177,6 +177,12 @@ \subsection{For-Statement}\label{for-statement}
 \end{lstlisting}
 The rules for \lstinline!for!-statements are the same as for \lstinline!for!-expressions in \cref{explicit-iteration-ranges-of-for-equations} -- except that the \lstinline!expression! of a \lstinline!for!-statement is not restricted to a parameter-expression.
 
+If the \lstinline!for!-statement contains event-generating expressions, any expression in \lstinline[language=grammar]!for-index! shall be evaluable.
+
+\begin{nonnormative}
+In general, the same event-generating expression requires distinct crossing functions for different iterations of the \lstinline!for!-loop, and the restriction ensures that the number of crossing functions is known during translation time.
+\end{nonnormative}
+
 \begin{example}
 \begin{lstlisting}[language=modelica]
 for i in 1 : 10 loop // i takes the values 1, 2, 3, $\ldots$, 10
@@ -202,11 +208,17 @@ \subsubsection{Implicit Iteration Ranges}\label{implicit-iteration-ranges}
 An iterator \lstinline!IDENT in range-expr! without the \lstinline!in range-expr! requires that the \lstinline!IDENT! appears as the subscript of one or several subscripted expressions, where the expressions are not part of an array in a component of an expandable connector.
 The dimension size of the array expression in the indexed position is used to deduce the \lstinline!range-expr! as \lstinline!1:size(array-expression,indexpos)! if the indices are a subtype of \lstinline!Integer!, or as \lstinline!E.e1:E.en! if the indices are of an enumeration type \lstinline!E = enumeration(e1, $\ldots$, en)!, or as \lstinline!false:true! if the indices are of type \lstinline!Boolean!.
 If it is used to subscript several expressions, their ranges must be identical.
-The \lstinline!IDENT! may also, inside a reduction expression, array constructor expression, \lstinline!for!-statement, or \lstinline!for!-equation, occur freely outside of subscript positions, but only as a reference to the variable \lstinline!IDENT!, and not for deducing ranges.
+There may not be assignments to the entire arrays that are subscripted with \lstinline!IDENT! inside the loop, but there may be assignments to individual elements or ranges of elements.
+
+\begin{nonnormative}
+The size of an array -- the iteration range -- can be evaluated on entry to the \lstinline!for!-loop, since the array size cannot change during the execution of the \lstinline!for!-loop.
+\end{nonnormative}
 
+The \lstinline!IDENT! may also, inside a reduction expression, array constructor expression, \lstinline!for!-statement, or \lstinline!for!-equation, occur freely outside of subscript positions, but only as a reference to the variable \lstinline!IDENT!, and not for deducing ranges.
 The \lstinline!IDENT! may also be used as a subscript for an array in a component of an expandable connector but it is only seen as a reference to the variable \lstinline!IDENT! and cannot be used for deducing ranges.
 
 \begin{example}
+Implicit iterator ranges for an \lstinline!Integer! subscript:
 \begin{lstlisting}[language=modelica]
   Real x[4];
   Real xsquared[:] = {x[i] * x[i] for i};
@@ -222,22 +234,25 @@ \subsubsection{Implicit Iteration Ranges}\label{implicit-iteration-ranges}
     xsquared3[i] := x[i]^2;
   end for;
 \end{lstlisting}
+\end{example}
 
+\begin{example}
+An array dimension's type of subscript does not matter for array compatibility, only the size of the array dimension matters.
+This is true also for array constructor expressions with implicit iterator ranges:
 \begin{lstlisting}[language=modelica]
 type FourEnums = enumeration(one, two, three, four);
+Real x[4];
 Real xe[FourEnums] = x;
-Real xsquared3[FourEnums] = {xe[i] * xe[i] for i};
-Real xsquared4[FourEnums] = {xe[i] * xe[i] for i in FourEnums};
+Real xsquared3[FourEnums] = {xe[i] * xe[i] for i in FourEnums};
+Real xsquared4[FourEnums] = {xe[i] * xe[i] for i};
 Real xsquared5[FourEnums] = {x[i] * x[i] for i};
 \end{lstlisting}
 \end{example}
 
-The size of an array -- the iteration range -- is evaluated on entry to the \lstinline!for!-loop and the array size shall not change during the execution of the \lstinline!for!-loop.
-
 \subsubsection{Types as Iteration Ranges}\label{types-as-iteration-ranges}
 
 The iteration range can be specified as \lstinline!Boolean! or as an enumeration type.
-This means iteration over the type from min to max, i.e.\ for \lstinline!Boolean! it is the same as \lstinline!false:true! and for an enumeration \lstinline!E! it is the same as \lstinline!E.min:E.max!.
+This means iteration over the type from min to max, i.e., for \lstinline!Boolean! it is the same as \lstinline!false:true! and for an enumeration \lstinline!E! it is the same as \lstinline!E.min:E.max!.
 This can be used for \lstinline!for!-loops and reduction expressions.
 
 \begin{example}
@@ -280,7 +295,8 @@ \subsection{While-Statement}\label{while-statement}
 end while
 \end{lstlisting}
 The \lstinline!expression! of a \lstinline!while!-statement shall be a scalar \lstinline!Boolean! expression.
-The \lstinline!while!-statement corresponds to while-statements in programming languages, and is formally defined as follows:
+
+The \lstinline!while!-statement corresponds to while-statements in other programming languages, and is formally defined as follows:
 \begin{enumerate}
 \item
   \label{while-execution-top}
@@ -291,6 +307,9 @@ \subsection{While-Statement}\label{while-statement}
   If the \lstinline!expression! of the \lstinline!while!-statement is true, the entire body of the \lstinline!while!-statement is executed (except if a \lstinline!break!-statement, see \cref{break-statement}, or a \lstinline!return!-statement, see \cref{return-statements}, is executed), and then execution proceeds at step~\ref{while-execution-top}.
 \end{enumerate}
 
+Event-generating expressions are neither allowed in the \lstinline!expression! nor in the loop body statements.
+A deprecated feature is that all expressions in a \lstinline!while!-statement are implicitly inside \lstinline!noEvent!.
+
 \subsection{Break-Statement}\label{break-statement}
 
 The \lstinline!break!-statement\index{break@\robustinline{break}} breaks the execution of the innermost \lstinline!while!- or \lstinline!for!-loop enclosing the \lstinline!break!-statement and continues execution after the \lstinline!while!- or \lstinline!for!-loop.
@@ -456,7 +475,7 @@ \subsubsection{Defining When-Statements by If-Statements}\label{defining-when-st
   end if;
 \end{lstlisting}
 with \lstinline!edge(A) = A and not pre(A)! and the additional guarantee, that the statements within this special \lstinline!if!-statement are only evaluated at event instants.
-The difference compared to the when-statements is that e.g.\ \lstinline!pre! may only be used on continuous-time real variables inside the body of a \lstinline!when!-clause and not inside these if-statements.
+The difference compared to the when-statements is that, e.g., \lstinline!pre! may only be used on continuous-time real variables inside the body of a \lstinline!when!-clause and not inside these if-statements.
 
 \subsection{Special Statements}\label{special-statements}
 
diff --git a/chapters/stream.tex b/chapters/stream.tex
index 5ca41dd7a..e36682ac6 100644
--- a/chapters/stream.tex
+++ b/chapters/stream.tex
@@ -386,7 +386,7 @@ \section{actualStream}\label{stream-operator-actualstream}\label{actualstream}
 wants to avoid events entirely, he/she may enclose the right-hand side
 of (1) with \lstinline!noEvent!.
 
-Equations like (2) might be used for monitoring purposes (e.g.\ plots), in order to inspect what the actual enthalpy of the fluid flowing through a port is.
+Equations like (2) might be used for monitoring purposes (e.g., plots), in order to inspect what the actual enthalpy of the fluid flowing through a port is.
 In this case, the user will probably want to see the change due to flow reversal at the exact instant, so an event should be generated.  If the user doesn't
 bother, then he/she should enclose the right-hand side of (2) with \lstinline!noEvent!.  Since the output of \lstinline!actualStream! will be discontinuous,
 it should not be used by itself to model physical behaviour (e.g., to compute densities used in momentum balances) -- \lstinline!inStream! should be used
diff --git a/chapters/synchronous.tex b/chapters/synchronous.tex
index 54e059dca..3e27d40ea 100644
--- a/chapters/synchronous.tex
+++ b/chapters/synchronous.tex
@@ -14,26 +14,21 @@ \chapter{Synchronous Language Elements}\label{synchronous-language-elements}
 
 \begin{itemize}
 \item
-  A periodic clock is defined with \lstinline!Clock(3)!. The argument
-  of \lstinline!Clock! defines the sampling interval (for details see \cref{clock-constructors}).
+  A periodic clock is defined with \lstinline!Clock(3)!.
+  The argument of \lstinline!Clock! defines the sampling interval (for details see \cref{clock-constructors}).
 \item
-  Clocked variables (such as \lstinline!yd!, \lstinline!xd!, \lstinline!ud!) are associated uniquely
-  with a clock and can only be directly accessed when the associated
-  clock is active. Since all variables in a clocked equation must belong
-  to the same clock, clocking errors can be detected at compile time. If
-  variables from different clocks shall be used in an equation, explicit
-  cast operators must be used, such as \lstinline!sample! to convert
-  from continuous-time to clocked discrete-time or \lstinline!hold! to
-  convert from clocked discrete-time to continuous-time.
+  Clocked variables (such as \lstinline!yd!, \lstinline!xd!, \lstinline!ud!) are associated uniquely with a clock and can only be directly accessed when the associated clock is active.
+  Since all variables in a clocked equation must belong to the same clock, clocking errors can be detected at compile time.
+  If variables from different clocks shall be used in an equation, explicit cast operators must be used, such as \lstinline!sample! to convert from continuous-time to clocked discrete-time or \lstinline!hold! to convert from clocked discrete-time to continuous-time.
 \item
-  A continuous-time variable is sampled at a clock tick with
-  \lstinline!sample!. The operator returns the value of the
-  continuous-time variable when the clock is active.
+  A continuous-time variable is sampled at a clock tick with \lstinline!sample!.
+  The operator returns the value of the continuous-time variable when the clock is active.
 \item
-  When no argument is defined for \lstinline!Clock!, the clock is
-  deduced by clock inference.
+  When no argument is defined for \lstinline!Clock!, the clock is deduced by clock inference.
 \item
-  For a \lstinline!when!-clause with an associated clock, all equations inside the \lstinline!when!-clause are clocked with the given clock.  All equations on an associated clock are treated together and in the same way regardless of whether they are inside a \lstinline!when!-clause or not.  This means that automatic sampling and hold of variables inside the \lstinline!when!-clause does not apply (explicit sampling and hold is required) and that general equations can be used in such \lstinline!when!-clauses (this is not allowed for \lstinline!when!-clauses with \lstinline!Boolean! conditions, that require a variable reference on the left-hand side of an equation).
+  For a \lstinline!when!-clause with an associated clock, all equations inside the \lstinline!when!-clause are clocked with the given clock.
+  All equations on an associated clock are treated together and in the same way regardless of whether they are inside a \lstinline!when!-clause or not.
+  This means that automatic sampling and hold of variables inside the \lstinline!when!-clause does not apply (explicit sampling and hold is required) and that general equations can be used in such \lstinline!when!-clauses (this is not allowed for \lstinline!when!-clauses with \lstinline!Boolean! conditions, that require a variable reference on the left-hand side of an equation).
 \item
   The \lstinline!when!-clause in the controller could also be removed
   and the controller could just be defined by the equations:
@@ -43,9 +38,8 @@ \chapter{Synchronous Language Elements}\label{synchronous-language-elements}
     ud = C * previous(xd) + D * yd;
 \end{lstlisting}
 \item
-  \lstinline!previous(xd)! returns the value of \lstinline!xd! at
-  the previous clock tick. At the first sample instant, the start value
-  of \lstinline!xd! is returned.
+  \lstinline!previous(xd)! returns the value of \lstinline!xd! at the previous clock tick.
+  At the first sample instant, the start value of \lstinline!xd! is returned.
 \item
   A discrete-time signal (such as \lstinline!ud!) is converted to a continuous-time signal with \lstinline!hold!.
 \item
@@ -60,7 +54,8 @@ \chapter{Synchronous Language Elements}\label{synchronous-language-elements}
 \section{Rationale for Clocked Semantics}\label{rationale-for-clocked-semantics}
 
 \begin{nonnormative}
-Periodically sampled control systems could also be defined with standard \lstinline!when!-clauses, see \cref{when-equations}, and the \lstinline!sample! operator, see \cref{event-related-operators-with-function-syntax}.  For example:
+Periodically sampled control systems could also be defined with standard \lstinline!when!-clauses, see \cref{when-equations}, and the \lstinline!sample! operator, see \cref{event-related-operators-with-function-syntax}.
+For example:
 \begin{lstlisting}[language=modelica]
 when sample(0, 3) then
   xd = A * pre(xd) + B * y;
@@ -79,8 +74,8 @@ \section{Rationale for Clocked Semantics}\label{rationale-for-clocked-semantics}
 Using standard \lstinline!when!-clauses works well for individual simple sampled blocks, but the synchronous approach using clocks and clocked equations provide the following benefits (especially for large sampled systems):
 \begin{enumerate}
 \item
-  Possibility to detect inconsistent sampling rate, since clock partitioning (see \cref{clock-partitioning}),
-  replaces the automatic sample and hold semantics. Examples:
+  Possibility to detect inconsistent sampling rate, since clock partitioning (see \cref{clock-partitioning}), replaces the automatic sample and hold semantics.
+  Examples:
   \begin{enumerate}
   \def\labelenumii{\alph{enumii}.}
   \item
@@ -88,60 +83,34 @@ \section{Rationale for Clocked Semantics}\label{rationale-for-clocked-semantics}
     controller part, but by accident different when-conditions are
     given, then this is accepted (no error is detected).
   \item
-    If a sampled data library such as the
-    Modelica\_LinearSystems2.Contoller library is used, at every block
-    the sampling of the block has to be defined as integer multiple of a
-    base sampling rate. If several blocks should belong to the same
-    controller part, and different integer multiples are given, then the
-    translator has to accept this (no error is detected).
+    If a sampled data library such as the Modelica\_LinearSystems2.Contoller library is used, at every block the sampling of the block has to be defined as integer multiple of a base sampling rate.
+    If several blocks should belong to the same controller part, and different integer multiples are given, then the translator has to accept this (no error is detected).
   \end{enumerate}
-  Note: Clocked systems can mix different sampling rates
-  in well-defined ways when needed.
+  Note: Clocked systems can mix different sampling rates in well-defined ways when needed.
 \item
-  Fewer initial conditions are needed, as only a subset of clocked
-  variables need initial conditions -- the clocked state variables (see \cref{clocked-state-variables}).
-  For a standard \lstinline!when!-clause all variables
-  assigned in a \lstinline!when!-clause must have an initial value
-  because they might be used, before they are assigned a value the first
-  time. As a result, all these variables are ``discrete-time states''
-  although in reality only a subset of them need an initial
-  value.
+  Fewer initial conditions are needed, as only a subset of clocked variables need initial conditions -- the clocked state variables (see \cref{clocked-state-variables}).
+  For a standard \lstinline!when!-clause all variables assigned in a \lstinline!when!-clause must have an initial value because they might be used, before they are assigned a value the first time.
+  As a result, all these variables are ``discrete-time states'' although in reality only a subset of them need an initial value.
 \item
-  More general equations can be used, compared to standard \lstinline!when!-clauses that require
-  a restricted form of equations where the left hand side has to be a variable, in order
-  to identify the variables that are assigned in the \lstinline!when!-clause.
-  This restriction can be circumvented for standard \lstinline!when!-clauses, but is
-  absent for clocked equations and make it more convenient to define
-  nonlinear control algorithms.
+  More general equations can be used, compared to standard \lstinline!when!-clauses that require a restricted form of equations where the left hand side has to be a variable, in order to identify the variables that are assigned in the \lstinline!when!-clause.
+  This restriction can be circumvented for standard \lstinline!when!-clauses, but is absent for clocked equations and make it more convenient to define nonlinear control algorithms.
 \item
-  Clocked equations allow clock inference,
-  meaning that the sampling need only be given once for a sub-system.
-  For a standard \lstinline!when!-clause the condition (sampling) must be explicitly
-  propagated to all blocks, which is tedious and error prone for large systems.
+  Clocked equations allow clock inference, meaning that the sampling need only be given once for a sub-system.
+  For a standard \lstinline!when!-clause the condition (sampling) must be explicitly propagated to all blocks, which is tedious and error prone for large systems.
 \item
-  Possible to use general continuous-time models in synchronous models (e.g.\ some advanced controllers use an inverse model of a plant in the feedforward path of the controller, see \textcite{ThummelEtAl2005InverseModels}).
+  Possible to use general continuous-time models in synchronous models (e.g., some advanced controllers use an inverse model of a plant in the feedforward path of the controller, see \textcite{ThummelEtAl2005InverseModels}).
   This powerful feature of Modelica to use a nonlinear plant model in a controller would require to export the continuous-time model with an embedded integration method and then import it in an environment where the rest of the controller is defined.
   With clocked equations, clocked controllers with continuous-time models can be directly defined in Modelica.
 \item
-  Clocked equations are straightforward to optimize because they are
-  evaluated exactly once at each an event instant.
-  In contrast a standard \lstinline!when!-clause with \lstinline!sample! conceptually
-  requires several evaluations of the model (in some cases tools
-  can optimize this to avoid unneeded evaluations).
-  The problem for the standard \lstinline!when!-clause is that after \lstinline!v!
-  is changed, \lstinline!pre(v)! shall be updated and the model re-evaluated,
-  since the equations could depend on \lstinline!pre(v)!.
-  For clocked equations this iteration can be omitted
-  since \lstinline!previous(v)! can only occur in the clocked equations
-  that are only run the first event iterations.
+  Clocked equations are straightforward to optimize because they are evaluated exactly once at each event instant.
+  In contrast a standard \lstinline!when!-clause with \lstinline!sample! conceptually requires several evaluations of the model (in some cases tools can optimize this to avoid unneeded evaluations).
+  The problem for the standard \lstinline!when!-clause is that after \lstinline!v! is changed, \lstinline!pre(v)! shall be updated and the model re-evaluated, since the equations could depend on \lstinline!pre(v)!.
+  For clocked equations this iteration can be omitted since \lstinline!previous(v)! can only occur in the clocked equations that are only run the first event iterations.
 \item
   Clocked subsystems using arithmetic blocks are straightforward to optimize.
-  When a standard math-block (e.g.\ addition) is part of a clocked sub-system it is automatically
-  clocked and only evaluated when the clocked equations trigger.
-  For standard \lstinline!when!-clauses one either needs a separate sampled math-block for each operation, or
-  it will conceptually be evaluated all the time.
-  However, tools may perform a similar optimization for standard \lstinline!when!-clauses
-  and it is only relevant in large sampled systems.
+  When a standard math-block (e.g., addition) is part of a clocked sub-system it is automatically clocked and only evaluated when the clocked equations trigger.
+  For standard \lstinline!when!-clauses one either needs a separate sampled math-block for each operation, or it will conceptually be evaluated all the time.
+  However, tools may perform a similar optimization for standard \lstinline!when!-clauses and it is only relevant in large sampled systems.
 \end{enumerate}
 \end{nonnormative}
 
@@ -158,7 +127,10 @@ \subsection{Clocks and Clocked Variables}\label{clocks-and-clocked-variables}
 %  \subfloat[A piecewise-constant variable.]{\includegraphics{piecewise}\label{fig:piecewise-constant-variable}}
 %  \subfloat[A clock variable.]{\includegraphics{clock}\label{fig:clock-variable}}
 %  \subfloat[A clocked variable.]{\includegraphics{clocked}\label{fig:clocked-variable}}
-%  \caption{The different kinds of discrete-time variables.  The \lstinline!hold! extrapolation of the clocked variable is illustrated with dashed green lines.}
+%  \caption{%
+%    The different kinds of discrete-time variables.
+%    The \lstinline!hold! extrapolation of the clocked variable is illustrated with dashed green lines.
+%  }
 %\end{figure}
 
 In \cref{discrete-time-expressions} the term \emph{discrete-time} Modelica expression and in \cref{continuous-time-expressions} the term \emph{continuous-time} Modelica expression is defined.
@@ -166,9 +138,10 @@ \subsection{Clocks and Clocked Variables}\label{clocks-and-clocked-variables}
 The different kinds of discrete-time variables in Modelica are defined below.
 
 \begin{definition}[Piecewise-constant variable]\index{piecewise-constant variable}
-(See \cref{discrete-time-expressions}.)  Variables $m(t)$ of base type \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, enumeration, and \lstinline!String! that are
-\emph{constant} inside each interval $t_{i} \leq t < t_{i+1}$ (i.e., piecewise constant continuous-time variables).  In other words, $m(t)$ changes
-value only at events: $m(t) = m(t_{i})$, for $t_{i} \leq t < t_{i+1}$.  Such variables depend continuously on time and they are discrete-time variables.
+(See \cref{discrete-time-expressions}.)
+Variables $m(t)$ of base type \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, enumeration, and \lstinline!String! that are \emph{constant} inside each interval $t_{i} \leq t < t_{i+1}$ (i.e., piecewise constant continuous-time variables).
+In other words, $m(t)$ changes value only at events: $m(t) = m(t_{i})$, for $t_{i} \leq t < t_{i+1}$.
+Such variables depend continuously on time and they are discrete-time variables.
 See \cref{fig:piecewise-constant-variable}.
 \end{definition}
 
@@ -198,27 +171,34 @@ \subsection{Clocks and Clocked Variables}\label{clocks-and-clocked-variables}
   \begin{center}
     \includegraphics{clock}
   \end{center}
-  \caption{A clock variable.  The value of a clock variable is not defined -- the plot marks only indicate \emph{when} the clock is active.}\label{fig:clock-variable}
+  \caption{%
+    A clock variable.
+    The value of a clock variable is not defined -- the plot marks only indicate \emph{when} the clock is active.
+  }\label{fig:clock-variable}
 \end{figure}
 
 \begin{definition}[Clocked variable]\label{def:clocked-variable}\index{clocked!variable}
-The elements of clocked variables $r(t_{i})$ are of base type \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, enumeration, \lstinline!String! that are associated uniquely with
-a clock $c(t_{i})$. A clocked variable can only be directly accessed at the event instant where the associated clock is active.  A constant and a parameter can always be used at a place
-where a clocked variable is required.
+The elements of clocked variables $r(t_{i})$ are of base type \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, enumeration, \lstinline!String! that are associated uniquely with a clock $c(t_{i})$.
+A clocked variable can only be directly accessed at the event instant where the associated clock is active.
+A constant and a parameter can always be used at a place where a clocked variable is required.
 \begin{nonnormative}
 Note that clock variables are not included in this list.
 This implies that clock variables cannot be used where clocked variables are required.
 \end{nonnormative}
 
-At time instants where the associated clock is not active, the value of a clocked variable can be inquired by using an explicit cast operator, see below.  In such a case \lstinline!hold! semantics is
-used, in other words the value of the clocked variable from the last event instant is used.  See \cref{fig:clocked-variable}.
+At time instants where the associated clock is not active, the value of a clocked variable can be inquired by using an explicit cast operator, see below.
+In such a case \lstinline!hold! semantics is used, in other words the value of the clocked variable from the last event instant is used.
+See \cref{fig:clocked-variable}.
 \end{definition}
 
 \begin{figure}[H]
   \begin{center}
     \includegraphics{clocked}
   \end{center}
-  \caption{A clocked variable.  The \lstinline!hold! extrapolation of the value at the last event instant is illustrated with dashed green lines.}\label{fig:clocked-variable}
+  \caption{
+    A clocked variable.
+    The \lstinline!hold! extrapolation of the value at the last event instant is illustrated with dashed green lines.
+  }\label{fig:clocked-variable}
 \end{figure}
 
 \subsection{Base-Clock and Sub-Clock Partitions}\label{base-clock-and-sub-clock-partitions}
@@ -226,8 +206,8 @@ \subsection{Base-Clock and Sub-Clock Partitions}\label{base-clock-and-sub-clock-
 There are two kinds of \firstuse[clock!partition]{clock partitions}:
 
 \begin{definition}[Base-clock partition]\index{base-clock partition}\index{clock!partition!base-clock}
-A base-clock partition identifies a set of equations and a set of variables which must be executed together in one task.  Different base-clock partitions can be associated to separate tasks for
-asynchronous execution.
+A base-clock partition identifies a set of equations and a set of variables which must be executed together in one task.
+Different base-clock partitions can be associated to separate tasks for asynchronous execution.
 \end{definition}
 
 \begin{definition}[Sub-clock partition]\index{sub-clock partition}\index{clock!partition!sub-clock}
@@ -237,10 +217,8 @@ \subsection{Base-Clock and Sub-Clock Partitions}\label{base-clock-and-sub-clock-
 
 \subsection{Argument Restrictions (Component Expression)}\label{argument-restrictions-component-expression}
 
-The built-in operators (with function syntax) defined in the following
-sections have partially restrictions on their input arguments that are
-not present for Modelica functions. To define the restrictions, the
-following term is used.
+The built-in operators (with function syntax) defined in the following sections have partially restrictions on their input arguments that are not present for Modelica functions.
+To define the restrictions, the following term is used.
 
 \begin{definition}[Component expression]\label{def:component-expression}\index{component!expression (argument restriction)}
 A component expression is a \lstinline[language=grammar]!component-reference! which is a valid expression, i.e., not referring to models or blocks with equations.
@@ -399,7 +377,10 @@ \section{Clock Constructors}\label{clock-constructors}
 If $\mathit{interval}$ is a parameter expression, the clock defines a periodic clock.
 
 \begin{nonnormative}
-Note, the clock is defined with \lstinline!previous($\mathit{interval}$)!.  Therefore, for sorting the input argument is treated as known.  The given interval and time shift can be modified by using the \lstinline!subSample!, \lstinline!superSample!, \lstinline!shiftSample! and \lstinline!backSample! operators on the returned clock, see \cref{sub-clock-conversion-operators}.  There are restrictions where this operator can be used, see \lstinline!Clock! expressions below.
+Note, the clock is defined with \lstinline!previous($\mathit{interval}$)!.
+Therefore, for sorting the input argument is treated as known.
+The given interval and time shift can be modified by using the \lstinline!subSample!, \lstinline!superSample!, \lstinline!shiftSample! and \lstinline!backSample! operators on the returned clock, see \cref{sub-clock-conversion-operators}.
+There are restrictions where this operator can be used, see \lstinline!Clock! expressions below.
 \end{nonnormative}
 \end{semantics}
 \end{operatordefinition*}
@@ -467,7 +448,8 @@ \section{Clock Constructors}\label{clock-constructors}
 \item
   Exactly one event clock.
 \item
-  A default clock, if neither a real interval, nor a rational interval nor an event clock is associated with a base partition.  In this case the default clock is associated with the fastest sub-clock partition.
+  A default clock, if neither a real interval, nor a rational interval nor an event clock is associated with a base partition.
+  In this case the default clock is associated with the fastest sub-clock partition.
   \begin{nonnormative}
   Typically, a tool will use \lstinline!Clock(1.0)! as a default clock and will raise a warning, that it selected a default clock.
   \end{nonnormative}
@@ -585,12 +567,15 @@ \subsection{Base-Clock Conversion Operators}\label{base-clock-conversion-operato
 \begin{semantics}
 Input argument $u$ is a continuous-time expression according to \cref{continuous-time-expressions}.
 The optional input argument $\mathit{clock}$ is of type \lstinline!Clock!, and can in a call be given as a named argument (with the name $\mathit{clock}$), or as positional argument.
-The operator returns a clocked variable that has $\mathit{clock}$ as associated clock and has the value of the left limit of $u$ when $\mathit{clock}$ is active (that is the value of $u$ just before the event of \lstinline!c! is triggered).
+The operator returns a clocked variable that has $\mathit{clock}$ as associated clock and has the value of the left limit of $u$ when $\mathit{clock}$ is active (that is the value of $u$ just before the event of $\mathit{clock}$ is triggered).
 If $\mathit{clock}$ is not provided, it is inferred, see \cref{sub-clock-inferencing}.
 \begin{nonnormative}
-Since the operator returns the left limit of $u$, it introduces an infinitesimal small delay between the continuous-time and the clocked partition.  This corresponds to the reality, where a sampled data system cannot act infinitely fast and even for a very idealized simulation, an infinitesimal small delay is present.  The consequences for the sorting are discussed below.
+Since the operator returns the left limit of $u$, it introduces an infinitesimal small delay between the continuous-time and the clocked partition.
+This corresponds to the reality, where a sampled data system cannot act infinitely fast and even for a very idealized simulation, an infinitesimal small delay is present.
+The consequences for the sorting are discussed below.
 
-Input argument $u$ can be a general expression, because the argument is continuous-time and therefore has always a value.  It can also be a constant, a parameter or a piecewise constant expression.
+Input argument $u$ can be a general expression, because the argument is continuous-time and therefore has always a value.
+It can also be a constant, a parameter or a piecewise constant expression.
 
 Note that \lstinline!sample! is an overloaded function:
 If \lstinline!sample! has two positional input arguments and the second argument is of type \lstinline!Real!, it is the operator from \cref{event-related-operators-with-function-syntax}.
@@ -625,7 +610,9 @@ \subsection{Base-Clock Conversion Operators}\label{base-clock-conversion-operato
   der(y) = 0;
 \end{lstlisting}
 
-The value of \lstinline!yc! at the first clock tick is $\text{\lstinline!yc!} = 2$ (and not $\text{\lstinline!yc!} = 1$).  The reason is that the continuous-time model \lstinline!der(y) + y = 2! is first initialized and after initialization \lstinline!y! has the value 2.  At the first clock tick at $\text{\lstinline!time!} = 0$, the left limit of \lstinline!y! is 2 and therefore $\text{\lstinline!yc!} = 2$.
+The value of \lstinline!yc! at the first clock tick is $\text{\lstinline!yc!} = 2$ (and not $\text{\lstinline!yc!} = 1$).
+The reason is that the continuous-time model \lstinline!der(y) + y = 2! is first initialized and after initialization \lstinline!y! has the value 2.
+At the first clock tick at $\text{\lstinline!time!} = 0$, the left limit of \lstinline!y! is 2 and therefore $\text{\lstinline!yc!} = 2$.
 \end{example}
 
 \subsubsection{Sorting of a Simulation Model}
@@ -661,11 +648,14 @@ \subsection{Sub-Clock Conversion Operators}\label{sub-clock-conversion-operators
 These operators have the following properties:
 \begin{itemize}
 \item
-  The input argument $u$ is a clocked expression or an expression of type \lstinline!Clock!.  (The operators can operate on all types of clocks.)  If $u$ is a clocked expression, the operator returns a clocked variable that has the same type as the expression.  If $u$ is an expression of type \lstinline!Clock!, the operator returns a \lstinline!Clock! -- except for \lstinline!noClock! where it is an error.
+  The input argument $u$ is a clocked expression or an expression of type \lstinline!Clock!.
+  (The operators can operate on all types of clocks.)
+  If $u$ is a clocked expression, the operator returns a clocked variable that has the same type as the expression.
+  If $u$ is an expression of type \lstinline!Clock!, the operator returns a \lstinline!Clock! -- except for \lstinline!noClock! where it is an error.
 \item
   The optional input arguments \lstinline!factor! (defaults to 0, with \lstinline!min = 0!), and \lstinline!resolution! (defaults to 1, with \lstinline!min = 1!) are parameter expressions of type \lstinline!Integer!.
 \item
-  Calls of the operators can use named arguments for the multi-letter arguments (i.e.\ not for $u$) with the given names, or positional arguments.
+  Calls of the operators can use named arguments for the multi-letter arguments (i.e., not for $u$) with the given names, or positional arguments.
 \begin{nonnormative}
 Named arguments can make the calls easier to understand.
 \end{nonnormative}
@@ -690,7 +680,9 @@ \subsection{Sub-Clock Conversion Operators}\label{sub-clock-conversion-operators
 superSample($u$, factor=$\mathit{factor}$)
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-The clock of \lstinline!y = superSample($u$, $\mathit{factor}$)! is $\mathit{factor}$ times faster than the clock of $u$.  At every tick of the clock of \lstinline!y!, the operator returns the value of $u$ from the last tick of the clock of $u$.  The first activation of the clock of \lstinline!y! coincides with the first activation of the clock of $u$, and then the interval between activations of the clock of $u$ is split equidistantly into $\mathit{factor}$ activations, such that the activation $1 + k \cdot \mathit{factor}$ of \lstinline!y! coincides with the $1 + k$ activation of $u$.
+The clock of \lstinline!y = superSample($u$, $\mathit{factor}$)! is $\mathit{factor}$ times faster than the clock of $u$.
+At every tick of the clock of \lstinline!y!, the operator returns the value of $u$ from the last tick of the clock of $u$.
+The first activation of the clock of \lstinline!y! coincides with the first activation of the clock of $u$, and then the interval between activations of the clock of $u$ is split equidistantly into $\mathit{factor}$ activations, such that the activation $1 + k \cdot \mathit{factor}$ of \lstinline!y! coincides with the $1 + k$ activation of $u$.
 \begin{nonnormative}
 Thus \lstinline!subSample(superSample($u$, $\mathit{factor}$), $\mathit{factor}$)! = $u$.
 \end{nonnormative}
@@ -714,7 +706,8 @@ \subsection{Sub-Clock Conversion Operators}\label{sub-clock-conversion-operators
 shiftSample($u$, shiftCounter=$k$, resolution=$\mathit{resolution}$)
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-The operator \lstinline!c = shiftSample($u$, $k$, $\mathit{resolution}$)! splits the interval between ticks of $u$ into $\mathit{resolution}$ equidistant intervals $i$.  The clock \lstinline!c! then ticks $k$ intervals $i$ after each tick of $u$.
+The operator \lstinline!c = shiftSample($u$, $k$, $\mathit{resolution}$)! splits the interval between ticks of $u$ into $\mathit{resolution}$ equidistant intervals $i$.
+The clock \lstinline!c! then ticks $k$ intervals $i$ after each tick of $u$.
 
 It leads to
 \begin{lstlisting}[language=modelica]
@@ -723,7 +716,8 @@ \subsection{Sub-Clock Conversion Operators}\label{sub-clock-conversion-operators
 \end{lstlisting}
 
 \begin{nonnormative}
-Note, due to the restriction of \lstinline!superSample! on event clocks, \lstinline!shiftSample! can only shift the number of ticks of the event clock, but cannot introduce new ticks.  Example:
+Note, due to the restriction of \lstinline!superSample! on event clocks, \lstinline!shiftSample! can only shift the number of ticks of the event clock, but cannot introduce new ticks.
+Example:
 \begin{lstlisting}[language=modelica]
 // Rational interval clock
 Clock u  = Clock(3, 10);            // ticks: 0, 3/10, 6/10, $\ldots$
@@ -792,7 +786,9 @@ \subsection{Sub-Clock Conversion Operators}\label{sub-clock-conversion-operators
 noClock($u$)
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-The clock of \lstinline!y = noClock($u$)! is always inferred, and $u$ must be part of the same base-clock as \lstinline!y!.  At every tick of the clock of \lstinline!y!, the operator returns the value of $u$ from the last tick of the clock of $u$.  If \lstinline!noClock($u$)! is called before the first tick of the clock of $u$, the start value of $u$ is returned.
+The clock of \lstinline!y = noClock($u$)! is always inferred, and $u$ must be part of the same base-clock as \lstinline!y!.
+At every tick of the clock of \lstinline!y!, the operator returns the value of $u$ from the last tick of the clock of $u$.
+If \lstinline!noClock($u$)! is called before the first tick of the clock of $u$, the start value of $u$ is returned.
 \end{semantics}
 \end{operatordefinition}
 
@@ -815,7 +811,8 @@ \subsection{Sub-Clock Conversion Operators}\label{sub-clock-conversion-operators
 \begin{nonnormative}
 Clarification of \lstinline!noClock! operator:
 
-Note, that \lstinline!noClock(u)! is not equivalent to \lstinline!sample(hold(u))!.  Consider the following model:
+Note, that \lstinline!noClock(u)! is not equivalent to \lstinline!sample(hold(u))!.
+Consider the following model:
 \begin{lstlisting}[language=modelica]
 model NoClockVsSampleHold
   Clock clk1 = Clock(0.1);
@@ -832,7 +829,8 @@ \subsection{Sub-Clock Conversion Operators}\label{sub-clock-conversion-operators
 end NoClockVsSampleHold;
 \end{lstlisting}
 
-Due to the infinitesimal delay of \lstinline!sample!, \lstinline!z! will not show the current value of \lstinline!x! as \lstinline!clk2! ticks, but will show its previous value (left limit).  However, \lstinline!y! will show the current value, since it has no infinitesimal delay.
+Due to the infinitesimal delay of \lstinline!sample!, \lstinline!z! will not show the current value of \lstinline!x! as \lstinline!clk2! ticks, but will show its previous value (left limit).
+However, \lstinline!y! will show the current value, since it has no infinitesimal delay.
 \end{nonnormative}
 
 Note that it is not legal to compute the derivative of the \lstinline!sample!, \lstinline!subSample!, \lstinline!superSample!, \lstinline!backSample!,
@@ -851,7 +849,9 @@ \section{Clocked When-Clause}\label{clocked-when-clause}
 end when;
 \end{lstlisting}
 
-The clocked \lstinline!when!-clause cannot be nested and does not have any \lstinline!elsewhen! part.  It cannot be used inside an algorithm.  General equations are allowed in a clocked \lstinline!when!-clause.
+The clocked \lstinline!when!-clause cannot be nested and does not have any \lstinline!elsewhen! part.
+It cannot be used inside an algorithm.
+General equations are allowed in a clocked \lstinline!when!-clause.
 
 For a clocked \lstinline!when!-clause, all equations inside the \lstinline!when!-clause are clocked with the same clock given by the $\mathit{clockExpression}$.
 
@@ -861,7 +861,8 @@ \section{Clock Partitioning}\label{clock-partitioning}
 equations are inferred.
 
 \begin{nonnormative}
-Typically clock partitioning is performed before sorting the equations.  The benefit is that clocking and symbolic transformation errors are separated.
+Typically clock partitioning is performed before sorting the equations.
+The benefit is that clocking and symbolic transformation errors are separated.
 \end{nonnormative}
 
 Every clocked variable is uniquely associated with exactly one clock.
@@ -872,26 +873,25 @@ \section{Clock Partitioning}\label{clock-partitioning}
 The associated clock is either explicitly defined by a \lstinline!when!-clause, see \cref{sub-clock-conversion-operators}, or it is implicitly defined by the requirement that a clocked equation, a clocked expression and a clocked algorithm section must have the same clock as the variables used in them with exception of the expressions used as first arguments in the conversion operators of \cref{partitioning-operators}.
 \firstuse[clock!inference]{Clock inference} means to infer the clock of a variable, an equation, an expression or an algorithm section if the clock is not explicitly defined and is deduced from the required properties in the previous two paragraphs.
 
-All variables in an expression without clock conversion operators must
-have the same clock to infer the clocks for each variable and
-expression. The clock inference works both forward and backwards
-regarding the data flow and is also being able to handle algebraic
-loops. The clock inference method uses the set of variable incidences of
-the equations, i.e., what variables that appear in each equation.
+All variables in an expression without clock conversion operators must have the same clock to infer the clocks for each variable and expression.
+The clock inference works both forward and backwards regarding the data flow and is also being able to handle algebraic loops.
+The clock inference method uses the set of variable incidences of the equations, i.e., what variables that appear in each equation.
 
-Note that incidences of the first argument of clock conversion operators
-of \cref{partitioning-operators} are handled specially.
+Note that incidences of the first argument of clock conversion operators of \cref{partitioning-operators} are handled specially.
+
+\begin{nonnormative}
+As clock partitions are solely determined by the equations, two different clock partitions can have clocks defined by the same expressions.
+It is a quality of implementation issue that such partitions are executed synchronously, e.g., by putting them in the same task in a real-time simulation context.
+\end{nonnormative}
 
 \subsection{Flattening of Model}\label{flattening-of-model}
 
-The clock partitioning is conceptually performed after model flattening,
-i.e., redeclarations have been elaborated, arrays of model components
-expanded into scalar model components, and overloading resolved.
+The clock partitioning is conceptually performed after model flattening, i.e., redeclarations have been elaborated, arrays of model components expanded into scalar model components, and overloading resolved.
 Furthermore, function calls to inline functions have been inlined.
 
 \begin{nonnormative}
-This is called \emph{conceptually}, because a tool might do this more efficiently in a different way, provided the result is the same as if everything is flattened.  For example,
-array and matrix equations and records don't not need to be expanded if they have the same clock.
+This is called \emph{conceptually}, because a tool might do this more efficiently in a different way, provided the result is the same as if everything is flattened.
+For example, array and matrix equations and records don't not need to be expanded if they have the same clock.
 \end{nonnormative}
 
 Furthermore, each non-trivial expression (non-literal, non-constant, non-parameter, non-variable), $\mathit{expr}_{i}$, appearing as first argument of a clock conversion operator (except \lstinline!hold! and \lstinline!backSample!) is recursively replaced by a unique variable, $v_{i}$, and the equation $v_{i} = \mathit{expr}_{i}$ is added to the equation set.
@@ -1010,6 +1010,7 @@ \subsection{Sub-Clock Partitioning}\label{sub-clock-partitioning}
 
 The resulting set of connected components, is the partitioning of the equations and variables, $S_{ij} = \left\langle E_{ij},\, V_{ij} \right\rangle$, according to sub-clocks.
 
+The connected components (corresponding to the sub-clocks) are then further split into strongly connected components corresponding to systems of equations.
 The resulting sets of equations and variables shall be possible to solve separately, meaning that systems of equations cannot involve different sub-clocks.
 
 It can be noted that:
@@ -1043,6 +1044,33 @@ \subsection{Sub-Clock Partitioning}\label{sub-clock-partitioning}
 \end{lstlisting}
 \end{example}
 
+\begin{example}
+Forbidding systems of equations involving different sub-clocks means that the following is forbidden:
+\begin{lstlisting}[language=modelica]
+  Real a;
+  //Real x=a+z;
+  Real y=superSample(a+z, 2);
+  Real z;
+equation
+  a+z = sample(time, Clock(1,100));
+  0 = subSample(y, 2)+a;
+\end{lstlisting}
+Here \lstinline!a! and \lstinline!z! are part of one sub-clock, and \lstinline!y! of another, and the system of equations involve both of them.
+
+The following legal example solves the issues in the previous example by replacing \lstinline!a! by \lstinline!x-z! (and simplifying the equations).
+Additionally, it shows that it is not required that the sub-clocks can necessarily be sorted:
+\begin{lstlisting}[language=modelica]
+  Real x=sample(time, Clock(1,100));
+  Real y=superSample(x, 2);
+  Real z=subSample(y, 2)+x;
+\end{lstlisting}
+Here \lstinline!x! and \lstinline!z! are part of one sub-clock partition, and \lstinline!y! of another.
+The equations form three equation systems with one equation in each (hence trivially satisfying the requirement that only variables from one sub-clock partition are being solved).
+The equation systems need to be solved in a strict order, but the first and last equation system belong to one sub-clock, while the second equation system belongs to another sub-clock.
+This illustrates that there is no guarantee that the sub-clock partitions can be ordered in agreement with the equation systems.
+Note that equation systems with more than one equation are also allowed in sub-clock partitions.
+\end{example}
+
 \subsection{Sub-Clock Inferencing}\label{sub-clock-inferencing}
 
 For each base-clock partition, the base interval needs to be determined and for each sub-clock partition, the sub-sampling factors and shift need to be determined.
@@ -1051,7 +1079,8 @@ \subsection{Sub-Clock Inferencing}\label{sub-clock-inferencing}
 The model is erroneous if no solution exist.
 
 \begin{nonnormative}
-It must be possible to determine that the constraint set is valid at compile time.  However, in certain cases, it could be possible to defer providing actual numbers until run-time.
+It must be possible to determine that the constraint set is valid at compile time.
+However, in certain cases, it could be possible to defer providing actual numbers until run-time.
 \end{nonnormative}
 
 It is required that accumulated sub- and supersampling factors in the range of 1 to 2\textsuperscript{63} can be handled.
@@ -1071,10 +1100,8 @@ \section{Discretized Partition}\label{continuous-time-equations-in-clocked-parti
 methods between clock ticks, e.g., a very fast sub-system with an implicit solver with a small step-size and a slow sub-system with an explicit solver with a large step-size.
 \end{nonnormative}
 
-With the language elements defined in this section, continuous-time
-equations can be used in clocked partitions. Hereby, the continuous-time
-equations are solved with the defined integration method between clock
-ticks.
+With the language elements defined in this section, continuous-time equations can be used in clocked partitions.
+Hereby, the continuous-time equations are solved with the defined integration method between clock ticks.
 
 From the view of the continuous-time partition, the clock ticks are not interpreted as events, but as step-sizes of the integrator that the integrator must exactly hit.
 Hence, no event handling is triggered at clock ticks (provided an explicit event is not triggered from the model at this time instant).
@@ -1091,14 +1118,10 @@ \section{Discretized Partition}\label{continuous-time-equations-in-clocked-parti
 However, even if relations do not generate events, when-clauses and operators \lstinline!edge! and \lstinline!change! should behave as normal.
 \end{nonnormative}
 
-From the view of the clocked partition, the continuous-time
-partition is discretized and the discretized continuous-time variables
-have only a value at a clock tick. Therefore, such a partition is
-handled in the same way as any other clocked partition. Especially,
-operators such as \lstinline!sample!, \lstinline!hold!, \lstinline!subSample! must be used to communicate
-signals of the discretized partition with other
-partitions. Hereby, a discretized partition is treated similarly as a
-clocked partition.
+From the view of the clocked partition, the continuous-time partition is discretized and the discretized continuous-time variables have only a value at a clock tick.
+Therefore, such a partition is handled in the same way as any other clocked partition.
+Especially, operators such as \lstinline!sample!, \lstinline!hold!, \lstinline!subSample! must be used to communicate signals of the discretized partition with other partitions.
+Hereby, a discretized partition is treated similarly as a clocked partition.
 
 
 \subsection{Clocked and Discretized Partitions}\label{clocked-discrete-time-and-clocked-discretized-continuous-time-partition}\label{clocked-and-discretized-partition}
@@ -1139,8 +1162,8 @@ \subsection{Solver Methods}\label{solver-methods}
 A predefined type \lstinline!ModelicaServices.Types.SolverMethod! defines the methods supported by the respective tool by using the \lstinline!choices! annotation.
 
 \begin{nonnormative}
-The \lstinline!ModelicaServices! package contains tool specific definitions.  A string is used instead of an enumeration, since different tools might have different values and then the
-integer mapping of an enumeration is misleading since the same value might characterize different integrators.
+The \lstinline!ModelicaServices! package contains tool specific definitions.
+A string is used instead of an enumeration, since different tools might have different values and then the integer mapping of an enumeration is misleading since the same value might characterize different integrators.
 \end{nonnormative}
 
 The following names of solver methods are standardized:
@@ -1168,8 +1191,9 @@ \subsection{Solver Methods}\label{solver-methods}
 \lstinline!interval()! using a solution method defined in the simulation environment.
 
 \begin{nonnormative}
-An example of such a solution method could be to have a table of the clocks that are associated with discretized partitions and a method selection per clock.  In such
-a case, the solution method might be a variable step solver with step-size control that integrates between two clock ticks. The simulation environment might also combine all partitions associated with method \lstinline!"External"!, as well as all continuous-time partitions, and integrate them together with the solver selected by the simulation environment.
+An example of such a solution method could be to have a table of the clocks that are associated with discretized partitions and a method selection per clock.
+In such a case, the solution method might be a variable step solver with step-size control that integrates between two clock ticks.
+The simulation environment might also combine all partitions associated with method \lstinline!"External"!, as well as all continuous-time partitions, and integrate them together with the solver selected by the simulation environment.
 \end{nonnormative}
 
 If the solver method is \emph{not} \lstinline!"External"!, then the partition is
@@ -1262,7 +1286,8 @@ \subsection{Solver Methods}\label{solver-methods}
 equation
   der(x) = -x + u;
 \end{lstlisting}
-shall be transformed to a discretized partition with the \lstinline!"ExplicitEuler"! method.  The following model is a manual implementation:
+shall be transformed to a discretized partition with the \lstinline!"ExplicitEuler"! method.
+The following model is a manual implementation:
 \begin{lstlisting}[language=modelica]
   input Real u;
   parameter Real x_start = 1;
@@ -1289,7 +1314,7 @@ \subsection{Solver Methods}\label{solver-methods}
 For the implicit integration methods the efficiency can be enhanced by utilizing the discretization formula during the symbolic transformation of the equations.
 For example, linear differential equations are then mapped to linear and not non-linear algebraic equation systems, and also the structure of the equations can be utilized.
 For details see \textcite{ElmqvistOtterCellier1995InlineIntegration}.
-It might be necessary to associate additional data for an implicit integration method, e.g.\ the relative tolerance to solve the non-linear algebraic equation systems, or the maximum number of iterations in case of hard realtime requirements.
+It might be necessary to associate additional data for an implicit integration method, e.g., the relative tolerance to solve the non-linear algebraic equation systems, or the maximum number of iterations in case of hard realtime requirements.
 This data is tool specific and is typically either defined with a vendor annotation or is given in the simulation environment.
 \end{nonnormative}
 
@@ -1361,17 +1386,15 @@ \subsection{Inferencing of solverMethod}\label{inferencing-of-solvermethod}
 
 \section{Initialization of Clocked Partitions}\label{initialization-of-clocked-partitions}
 
-The standard scheme for initialization of Modelica models does not apply
-for clocked partitions. Instead, initialization is
-performed in the following way:
+The standard scheme for initialization of Modelica models does not apply for clocked partitions.
+Instead, initialization is performed in the following way:
 \begin{itemize}
 \item
   Variables in clocked partitions cannot be used in initial equation or
   initial algorithm sections.
 \item
   Attribute \lstinline!fixed! cannot be applied to variables in clocked partitions.
-  The attribute \lstinline!fixed! is true for variables to which
-  \lstinline!previous! is applied, otherwise false.
+  The attribute \lstinline!fixed! is true for variables to which \lstinline!previous! is applied, otherwise false.
 \end{itemize}
 
 \section{Other Operators}\label{other-operators}
@@ -1396,7 +1419,9 @@ \section{Other Operators}\label{other-operators}
 firstTick($u$)
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-This operator returns true at the first tick of the clock of the expression, in which this operator is called.  The operator returns false at all subsequent ticks of the clock.  The optional argument $u$ is only used for clock inference, see \cref{clock-partitioning}.
+This operator returns true at the first tick of the clock of the expression, in which this operator is called.
+The operator returns false at all subsequent ticks of the clock.
+The optional argument $u$ is only used for clock inference, see \cref{clock-partitioning}.
 \end{semantics}
 \end{operatordefinition}
 
@@ -1405,7 +1430,9 @@ \section{Other Operators}\label{other-operators}
 interval($u$)
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-This operator returns the interval between the previous and present tick of the clock of the expression, in which this operator is called.  The optional argument $u$ is only used for clock inference, see \cref{clock-partitioning}.  At the first tick of the clock the following is returned:
+This operator returns the interval between the previous and present tick of the clock of the expression, in which this operator is called.
+The optional argument $u$ is only used for clock inference, see \cref{clock-partitioning}.
+At the first tick of the clock the following is returned:
 \begin{enumerate}
 \item If the specified clock interval is a parameter expression, this value is returned.
 \item Otherwise the start value of the variable specifying the interval is returned.
@@ -1416,8 +1443,8 @@ \section{Other Operators}\label{other-operators}
 \end{operatordefinition}
 
 \begin{example}
-A discrete PI controller is parameterized with the parameters of a continuous PI controller, in order that the discrete block is robust against changes in the sample
-period.  This is achieved by discretizing a continuous PI controller (here with an implicit Euler method):
+A discrete PI controller is parameterized with the parameters of a continuous PI controller, in order that the discrete block is robust against changes in the sample period.
+This is achieved by discretizing a continuous PI controller (here with an implicit Euler method):
 \begin{lstlisting}[language=modelica]
 block ClockedPI
   parameter Real T "Time constant of continuous PI controller";
@@ -1497,7 +1524,8 @@ \section{Semantics}\label{semantics}
 end ClockTicks;
 \end{lstlisting}
 
-A possible implementation model is shown below using Modelica~3.2 semantics.  The base-clock is determined to 0.001 seconds and the sub-sampling factors to 1000 and 60000.
+A possible implementation model is shown below using Modelica~3.2 semantics.
+The base-clock is determined to 0.001 seconds and the sub-sampling factors to 1000 and 60000.
 
 \begin{lstlisting}[language=modelica]
 model ClockTicksWithModelica32
diff --git a/chapters/unitexpressions.tex b/chapters/unitexpressions.tex
index d40b9cd4b..6e9a61a7f 100644
--- a/chapters/unitexpressions.tex
+++ b/chapters/unitexpressions.tex
@@ -1,6 +1,6 @@
 \chapter{Unit Expressions}\label{unit-expressions}
 
-Unless otherwise stated, the syntax and semantics of unit expressions in Modelica conform with the international standards \emph{International System of Units (SI)} by BIPM superseding parts of ISO 31/0-1992 \emph{General principles concerning quantities, units and symbols} and ISO 1000-1992 \emph{SI units and recommendations for the use of their multiples and of certain other units}.
+Unless otherwise stated, the syntax and semantics of unit expressions in Modelica (for example, \cref{real-type} or \cref{axis-properties}) conform with the international standards \emph{International System of Units (SI)} by BIPM superseding parts of ISO 31/0-1992 \emph{General principles concerning quantities, units and symbols} and ISO 1000-1992 \emph{SI units and recommendations for the use of their multiples and of certain other units}.
 Unfortunately, these standards do not define a formal syntax for unit expressions.
 There are recommendations and Modelica exploits them.
 
diff --git a/mls.bib b/mls.bib
index 6881d89d9..a5de3e9e3 100644
--- a/mls.bib
+++ b/mls.bib
@@ -7,7 +7,7 @@ @Article{Pantelides1988ConsistentInitialization
   volume = {9},
   number = {2},
   pages = {213–-231},
-  url = {http://epubs.siam.org/doi/abs/10.1137/0909014},
+  url = {https://doi.org/10.1137/0909014},
 }
 
 @Article{BenvenisteEtAl2003SynchronousTwelveYearsLater,
@@ -83,6 +83,13 @@ @Manual{Pouzet2006LucidSynchrone30
   url = {http://www.di.ens.fr/~pouzet/lucid-synchrone/},
 }
 
+@Manual{GettextManual,
+  author = {Drepper, Ulrich and Meyering, Jim and Pinard, François and Haible, Bruno},
+  title = {GNU gettext tools, version 0.21},
+  year = {2020},
+  url = {https://www.gnu.org/software/gettext/manual/},
+}
+
 @InProceedings{Buerger2019SelectiveModel,
   author = {Bürger, Christoff},
   title = {Modelica language extensions for practical non-monotonic modelling: on the need for \emph{selective} model extension},
diff --git a/mlsshared.sty b/mlsshared.sty
index 7d8306980..16dad2f7b 100644
--- a/mlsshared.sty
+++ b/mlsshared.sty
@@ -227,3 +227,6 @@
 % Text mode additions
 \newcommand{\textgreatereq}{$\geq$}
 \newcommand{\textlesseq}{$\leq$}
+% For simpler links:
+\newcommand{\specpull}[1]{\href{https://github.com/modelica/ModelicaSpecification/pull/#1}{\#{#1}}}
+\newcommand{\specissue}[1]{\href{https://github.com/modelica/ModelicaSpecification/issue/#1}{\#{#1}}}
diff --git a/preamble.tex b/preamble.tex
index 5e0330bed..6e6868246 100644
--- a/preamble.tex
+++ b/preamble.tex
@@ -245,7 +245,6 @@
 }
 \makeatother% As long as this file isn't a normal package included with \usepackage...
 
-
 % Like \firstuse, but when speaking of a term that hasn't been introduced.
 % Produces same appearance as \firstuse, but doesn't add anything to the index.
 \newcommand{\willintroduce}[1]{\firstuse[---]{#1}}
diff --git a/styleguide.md b/styleguide.md
index 03a66a916..44db4e73d 100644
--- a/styleguide.md
+++ b/styleguide.md
@@ -189,6 +189,18 @@ Fixed ordinals: 1st, 2nd, 3rd.
 Symbolic ordinals: $n$th, $(n+1)$th.
 ```
 
+## Inline code
+
+Inline code is typically formatted using just the `\lstinline` macro.
+
+Since the change of type face can be very hard to notice for small code fragments, single quotes may sometimes be used to emphasize the distinction from the surrounding text, unless the code fragment consists of a single identifier (consistent presentation of identifiers is given higher priority than clarity of presentation in this case).
+For example:
+```
+… and prepending the reduction expression with ``\lstinline!functionName(!''.
+```
+
+Avoid overusing quotes around code fragments, especially for multi-letter fragments.
+
 ## Code listings
 
 ### Modelica listings
@@ -242,3 +254,8 @@ When a sentence starts with inline code,
 this may be rewritten using _The_ inserted before the inline code to avoid a lower case letter at the beginning of the sentence:
 
 > The `import`-clauses are not inherited.
+
+### Wrap punctuations around some abbreviations 
+
+Always use comma (or colon if the following text starts on new line) _after_ "e.g." and "i.e."; and use comma or some other punctuation such as "(", "--", or "." before them.
+This also avoids the need to guard the space after the dot.