Due to the lack of implementation of a locking feature that should have prevented concurrent editing of a module (as already exists when editing an article), a fatal error can be generated like this:

• take a fresh installed Joomla! 6
• open a browser instance in admin mode
• make sure the Global Configuration > System > Debug System is set to 'No' and Global Configuration > Server > Error Reporting is set to 'None'
• create at least one test page with no matter what content (say, a short text)
• create a new user with Publisher rights
• create a new custom module with no matter what content (say, another short text)
• place the module to whatever position (say, top-a)
• go to module Permissions tab and allow Front Editing for Publisher category
• save the module, but do not exit
• open another browser instance in frontend mode
• login with the user with Publisher rights
• click on the module as to edit it
• click either on 'Save' or 'Save & Close' button (no need to do any actual editing)
=> crash / The server returned a "500 - Whoops, looks like something went wrong."
• by going back in browser, the previous page will display normally, i.e. only the editing save action fails

Additional test:
• in admin area, set the Error Reporting to 'Simple'
• enter the module again (but no need to do anything)
• in frontend, log out then log in the same user with Publisher rights
• repeat the editing attempt
=> now an exception is listed saying 'Serialization of 'SimpleXMLElement' is not allowed' with this report:

Exception
in C:\wamp64\www\j6\libraries\src\Session\Storage\JoomlaStorage.php (line 146)

141    * @since   4.0.0
142    */
143    public function close(): void
144    {
145        // Before storing data to the session, we serialize and encode the Registry
146        $_SESSION['joomla'] = base64_encode(serialize($this->data));
147
148        parent::close();
149    }
150
151    /**

serialize(object(Registry))
in C:\wamp64\www\j6\libraries\src\Session\Storage\JoomlaStorage.php (line 146)
...
JoomlaStorage->close()

More additional test:

• in admin area, set the Debug System to 'Yes'
• enter the module again (but no need to do anything)
• etc.
=> now the save action appears to succeed (actually, a real edit there it even saves correctly), except that some layout around the module title may appear strange and the 'Save & Close' will only save but do not close the edit dialog
• click the 'Cancel' button to close the edit dialog

Expected:

While other user [with elevated rights] is already editing the module in question, a padlock should appear over (or instead) the edit button in frontend, blocking any editing attempt there – exactly like already happens when performing the above scenario but on an article instead of module.

When entering the module edit via frontend, in database > #__modules > the checked_out and checked_out_time entries remain NULL, which probably should be filled with the appropriate data (and proper frontend / backend flag).

(unconfirmed) It seems that this only happens when the frontend editing attempt is performed by a user that has not been granted Super User rights.