clarification

docs/source/syntaxreference.rst

@@ -694,8 +694,9 @@ So for instance::
     Examples of these second 'convenience' definition are library routines such as ``cbm.STOP2`` and ``cbm.GETIN2``,
     that only return a single value where the "official" versions ``STOP`` and ``GETIN`` always return multiple values.
 
-**Skipping values:** you are allowed to omit assignments of one or more values by putting ``void`` as the assignment target.
-One of the cases where this is useful is with boolean values returned in status flags such as the carry flag.
+**Skipping values:** Instead of using ``void`` to ignore the result of a subroutine call altogether,
+you can also use it as a placeholder name in a multi-assignment. This skips assignment of the return value in that place.
+One of the cases where this is useful, is with boolean values returned in status flags such as the carry flag.
 Storing that flag as a boolean in a variable first, and then possibly adding an ``if flag...`` statement afterwards, is a lot less
 efficient than just keeping the flag as-is and using a conditional branch such as ``if_cs`` to do something with it.
 So in the case above that could be::

docs/source/todo.rst

@@ -81,7 +81,6 @@ What if we were to re-introduce Structs in prog8? Some thoughts:
 Other language/syntax features to think about
 ---------------------------------------------
 
-- allow returning multiple values from normal (non-asmsub) subroutines as well?  Once that is done we can also clean up more of the library routines that now struggle to return multiple values.
 - add (rom/ram)bank support to romsub.   A call will then automatically switch banks, use callfar and something else when in banked ram.
   challenges: how to not make this too X16 specific? How does the compiler know what bank to switch (ram/rom)?
   How to make it performant when we want to (i.e. NOT have it use callfar/auto bank switching) ?