Proposed solution: Introduce new capability type: 'captype' => 'guestwrite' for the capabilities that can be added to the guest role. For example, complete feedback, see MDL-26743
Obviously, any module that defines such capabilities must provide anti-spam protection (i.e. recaptcha).

-----------
Original description:
-----------

Currently it is not possible to allow write access for guests. This is due to a Moodle policy of never allowing guests write access to prevent spam and to minimize attacking vectors (eg. possibility of XSS by anonymous users, etc.).
The current behavior is documented in several places:

• The default guest role description: "Guests have minimal privileges and usually can not enter text anywhere."
• The Guest role wiki page: "Guests ALWAYS have "read-only" access - meaning they can't leave any posts or otherwise mess up the course for real students."
• The description for the "Role for visitors" setting on the user policy admin settings page: "Things like creating posts still require the user to log in properly."

I understand the concerns about allowing guests write access but I think there are valid use cases ¹ to do so regardless.
Another point is that the setting possibilities with the capability and role system of Moodle 2.x (incorrectly) suggests that it would be possible to grant the guest role write access eg. for the database activity module (mod/data:writeentry).

The proposed workarounds of using the "No authentication" authentication method or using a dedicated user with public login credentials did not solve the problem completely.
This users will of course also get the role defined with the "Default role for all users" setting (by default this is the authenticated user role). But due to the algorithm of checking capabilities (calculate the combination of capability settings of all roles the user has in a specific context) it is not possible to give this dedicated user less capabilities than a normal user in system context but override this to explicit allow some specific things in a lower context. ²

All this brings me to the proposal of adding an option to enable write access for guests regardless to the security concerns. I state explicit that this should not be enabled by default. For all I care, we could "hide" this settings under the security section of the site administration and add warnings about the risks.
The capability and role system we have is almost good considered. But it should be possible to use its complete power by allowing an admin to configure it completely to fit their needs. And not to restrict it. An admin should know what he is doing.
Additionally to prevent misunderstandings, as long as this setting is not enabled the corresponding capabilities should not be displayed while editing the guest role (more specifically a role based on the guest archetype or the role that is selected for the "Role of visitors").

Forum discussion: https://moodle.org/mod/forum/discuss.php?d=340847

¹ This is my personal experience and many Moodle tracker issues document this too:

• using a database activity as a job board MDL-19852
• using a forum as a help desk tool: MDL-592
• some more issues without a named background: MDL-11691, MDL-13432, MDL-12917

² The prevent setting works just for overrides within the same role and prohibit setting can't be overridden (for a good reason). See the Override permissions wiki page for details. Maybe an additional setting "between" prevent and prohibit would be useful. But this needs another tracker issue.