You can decrease the protection level by editing the System Config value for "workflow_protection_level". Here are some notes on the various protection levels:
At level 10, all triggers fired from within a workflow are skipped.
There currently is no way to block two separate workflows that fire each other.
The only thing we can do at this stage is block all workflows from firing other workflows.
At some point, we can relax this rule and attempt warn the user of a potential circular workflow.
At level 8, block a nested event using the workflow instance.
When trying to isolate a nested trigger, we cannot use the audit token directly as we do not have a DB transaction across all activities.
Instead we use the Workflow Instance ID as it is static across the entire workflow.
So, we lookup the Workflow Instance ID and use it in place of the audit token.
At level 7, block a nested event using the workflow instance and the audit table.
This filter is slightly more permissive, but may not catch anything not already filtered above.
At level 5, a workflow cannot fire another identical workflow within the same activity.
This filter will only catch a workflow that updates itself or creates another new record.
However, I'm not sure that the problem is the protection level as it sounds like it is doing what we expect. You are modifying the record inside a workflow and the protection level is preventing the workflow from firing again. This sounds like desired behavior. So, we probably need to research more into why the field is not getting updated.
The problem may be related to updating a custom field. Can you try to update a core field within the module as a test of the workflow engine?