diff --git a/meetings/2024-11-19.md b/meetings/2024-11-19.md
index bbc39fd53156b16b04591806fc8537ef594a74a0..9cd3eb8525931af550fff7ff0d733c4c8be086a4 100644
--- a/meetings/2024-11-19.md
+++ b/meetings/2024-11-19.md
@@ -15,14 +15,14 @@
 We discussed reducing the size of the TTCN-3 core language by:
 
 * moving predefined functions, useful types and such into some kind of standard
-  library document.
+  library document.--- NO! WHY? What would be the advantage of it? 
 * Removing or deprecating features that could be substituted by other features
-  (e.g. arrays).
+  (e.g. arrays). --- If it will be only a shorthand of record of length (fixed value) then ok
 * Moving features that are not used by the majority of users, but are
   complementing the language into extension documents (e.g. procedure based
   communication).
 * Introducing new language concepts, that simplify the language (e.g. advanced
-  parameterization, closures, ...).
+  parameterization, closures, ...). NO, more details (adv/disadv) needed
 
 
 **Extensions**
@@ -43,7 +43,7 @@ A combination of various strategies is probable:
 
 # Coding style
 
-We should extend the ruleset for coding style of TTCN-3 examples (and conformance tests).
+We should extend the ruleset for coding style of TTCN-3 examples (and conformance tests).  -- Isn't it too large work?
 
 # Templates
 
@@ -93,14 +93,14 @@ template Point t := function (integer p) return Point {
 };
 ```
 
-Details need to be worked out in future discussions.
+Details need to be worked out in future discussions. -- if possible :)
 
 
 ## Special Template Symbols
 
 `all from`, `permutation`, `complement`, `subset`, `superset`, ..., do not need
 to be part of the core language. They could be implemented as library
-functions, as language extensions or even by user-defined dynamic matching.
+functions, as language extensions or even by user-defined dynamic matching. -- Only to be moved to extension, but NOT functions, user-defined (???) dynamic (???) matchning. Semantics and syntax must be kept.
 
 
 ## Inline Templates
@@ -111,11 +111,12 @@ annotations could be promoted to a type-conversion operator and template
 literals are already part of the language.
 
 //since now there is no type-conversion operator this is not true -- AG
+it is NOT type-conversion, but some kind of casting; inline templates are needed, used frequently
 
 
 ## Modified Templates
 
-Modified template and modified inline template syntax might be unified and simplified.
+Modified template and modified inline template syntax might be unified and simplified.  - HOW?
 
 
 ## List Templates
@@ -139,7 +140,11 @@ var template integer i := 1;
 Another simplification is to remove the differentiation between values and
 templates all together. For example: `var integer i := 1` would a shorthand for
 `var template(value) integer i := 1`.  
-This could also improve on compiler-pleasing through `valueof` and on
+
+I guess it would be useful in the opposite direction value:= (value)template  - discussion needed, for us the existing definition is ok
+This could also improve on compiler-pleasing 
+// it is not a point how complicated the compiler is; the language shall be easy-to-use
+through `valueof` and on
 operations such as `omit`, `present`, ...
 
 
@@ -148,22 +153,22 @@ operations such as `omit`, `present`, ...
 We discussed several aspects of the type system to identify opportunities for
 simplification:
 
-* Substitute `anytype` with `any`. Type switch from OOP extension would be a
-  good addition.
+* Substitute `anytype` with `any`. Type switch (---?????) from OOP extension would be a
+  good addition. - anytype will be in an extension; not to make backward incompatible solutions just for fun; would clash with any timer, any component, etc.
 * Arrays
-  * remove custom indexing.
-  * should become short-hand notation.
+  * remove custom indexing. -- ok
+  * should become short-hand notation.  -- ok
 * `set` and `set of` should be reviewed (compatibility with records,
-  replacement possible?)
+  replacement possible?) -- record of and set of are different ROI := {1,2,3}  SOI1:={1,2,3} SOI2 := {1,3,2} SOI1==SOI2 but ROI != SOI2
 * Should automatic typing be extended to unions and generics or should it
-  rather be moved to an extension?
+  rather be moved to an extension? NO
 * Map type:
   * Could be harmonized with `HashMap` from OOP extension.
-  * One could find overlap of `unmap` operations confusing.
-  * Some corner cases need clarification (e.g. `h[*] := {}`).
+  * One could find overlap of `unmap` operations confusing.  -- Unmap can be used for ports and maps; new keyword would have been better; but now will cause backward incompability
+  * Some corner cases need clarification (e.g. `h[*] := {}`). ---????
 * Sections describing type system could be simplified by introducing better
   type terminolgy (subtyping, type-alias, equality, assignment, component
-  variables, ...).
+  variables, ...). -- If only definition harmonisation, then ok; if meaning changes, not
 
 
 ## List Types
@@ -204,7 +209,7 @@ function equal(record of integer a, record of integer b) return boolean {
     }
     return true
 }
-```
+``` Shall be defined clearly, if the last elements are undefined it counts in the size/length or not
 
 ```ttcn3
 var record of integer a := {1,9};
@@ -236,19 +241,19 @@ removed. Further discussion is needed.
 `checkstate` is used to wait for a port to be ready. Further discussion is
 needed, whether `checkstate` could be improved or even removed.
 
-The `receive` part of `check` operation could be removed probably.
+The `receive` part of `check` operation could be removed probably. //check(template) is a shorthand of check(receive(template)) ?? shall be checked if parsr can handle it in a simple way
 
-The `trigger` could be substituted by `check`.
+The `trigger` could be substituted by `check`. // no, the trigger takes the value out of the queqe, while check do not
 
-Decoded field references, `decmatch`, `@decode` could be simplified. It needs to be checked whether `=>` can be removed.
+Decoded field references, `decmatch`, `@decode` could be simplified. It needs to be checked whether `=>` can be removed. //=> is used in OOP for a different purpose. One of them shall be be modified (probably in OOP)
 
 We discussed whether `goto` could be removed or substituted by named loops.
 
 Component's `call` operation might be moved into an extension document.
 
-External actions (`action`) do not need to be part of the core language.
+External actions (`action`) do not need to be part of the core language. //Shall be, this is how something can be written to screen during execution
 
-Modifiers (pe.g. `@deterministic`, `@nocase`, `@nodefault`, ...) or often overlooked. Further discussion is needed whether there's opportunity to generalize them.
+Modifiers (pe.g. `@deterministic`, `@nocase`, `@nodefault`, ...) or often overlooked. Further discussion is needed whether there's opportunity to generalize them.  //@deterministis - fuzzy/lazy; the other two are useful
 
 Attributes might be simplified:
   * remove `display`
@@ -258,12 +263,12 @@ Attributes might be simplified:
 
 ## Module organization
 
-`import` will be simplified if possible.  
-This would make `group` superfluous. However groups are used to structure
+`import` will be simplified if possible. // supported only import all 
+This would make `group` superfluous. However groups are used to structure  //group of instructions are useful
 modules and groups are also used by some language mappings.  
 Simplifying import would further require to discuss importing of imports.
 
-Visibility features (`friend`, `private`, `protected`) are used by testers,
+Visibility features (`friend`, `private`, `protected`) are used by testers,  //in many other languages these 3 categories exist
 seldom. It's used primarily by framework developers. Possible improvements need
 further discussion.
 
@@ -281,8 +286,8 @@ Language features that were neither removed nor moved into the core, will
 probably be merged into a common extensions document.
 
 * Performance and real-time extension:
-  * `wait` --> core
-  * `timestamp` --> core
+  * `wait` --> core  //discussion needed
+  * `timestamp` --> core  //discussion needed
   * remaining features --> extension
 * Configuration and Deployment features mostly stay as they are.
 * Advanced parameterisation:
@@ -291,14 +296,14 @@ probably be merged into a common extensions document.
   * Value parameterisation of types: Could be removed.
 * Behaviour types:
   * Behaviour types (and closures) will probably move to core to help
-    simplification.
-  * Deferred behaviour will be removed.
+    simplification.  // Further rationale is needed, just for fun is not enough
+  * Deferred behaviour will be removed.  
 * Continuous signals will probably go to historic state
 * Advanced matching:
-  * Dynamic matching will probably move to core.
+  * Dynamic matching will probably move to core.  //needs further discussion
   * Other features need further discussion.
 * Object oriented features:
-  * Exception-feature will probably move to core
-  * Some type operations (`=>`, `select class`) probably, too
+  * Exception-feature will probably move to core  //But how?
+  * Some type operations (`=>`, `select class`) probably, too  //select class without class?; => is used for another purpose in core
   * If and in what form user defined object will be merged into core is not
-    clear yet.
+    clear yet.  // What is user defined object?