actions_do() can consistently create broken/corrupted node types

I'd first like to apologize, this is a very long post.
Not only that, but I also do not have enough information yet to identify the actual cause of the problem.
This bug is tied into multiple modules and even drupal core is of suspect, I am very uncertain as to where to post this.
I am reporting this here as rules is the central focus to the problem.
I a marking this as a support request as I do not know the actual bug (only the symptoms) and I am looking for help as to what I should try next to identify the actual bug.
This is directly related to the code and design from:
- http://drupal.org/node/371728#comment-1694388
- http://drupal.org/node/276376#comment-1593096

Some weeks ago I noticed that some strange (broken) nodes were appearing on my system.
These broken nodes have no titles, bodies, or even a content type and therefore cannot be directly edited.
These nodes seem to be created by anonymous.
I am pretty sure anonymous should not be able to create nodes of non-existent or NULL node types!
The only things the nodes have are node id's and more importantly creation date/times.

Using the creation times, I began to attempt to match these creation dates with the watchdog logs.
The problem I found is that nothing was happening in the logs during these times, except for one message matching the exact date/time of the broken node creation date/time: Attempt to go to nonexistent transition (from 2 to 4)

That still didn't tell me what was causing the Workflow change, so I added Log to watchdogs to all of my rules.
A week later when the strange event happened again, I got my log results: Rule Set - Change to Submittal: [node:nid] - user: [user:user] - 127.0.0.1

I've got the state change and the exact rule set that caused it. After looking over the rule set's actions, I could find nothing obviously wrong. Now this rule set is triggered via a cron job which explains how "anonymous" could cause such damage. I immediately tried to schedule this cron job via scheduler so that the rule set would get triggered in few minutes of my editing.

And the node switched states properly, nothing weird in the logs, and no broken nodes appeared. I am missing the catalyst it seems.

Taking a different approach, I looked at all of the nodes I have that can change states and none of the logs either worklow, watchdog, or the content tracker show anything changing or attempting to during the times of the broken node creations (or anything remotely near).

Here is what the Rule set performs:
executes the Change To Submittal Rule, which performs:
- Load content by ID
- populate content with id nid's field 'field_date_submittal'
-- This deletes the scheduled date field so that the schedule does not get triggered again
- populate content with id nid's field 'field_state'
-- This changes the cck field of the workflow state, used for triggering rules
- Revoke content permissions by role
-- remove the ability for anonymous users to view the "submittal" node
- Execute custom php code

<?php
  $view = views_get_view('associated_files', TRUE);

  if (is_object($view)) {
    $view->set_display('default');
    $view->set_arguments(array($node_loaded->nid));
    $view->render();

    if ($view->result){
      foreach ($view->result as $result) {
        $current_node = node_load($result->nid);
        $actions = array('node_publish_action', 'node_save_action');
        $context['node'] = $current_node;
        actions_do($actions, $current_node, $context, NULL, NULL);
      }
    }
  }
  ?>

- Log to watchdog

I want to assume that the custom php code to be the most likely cause.
What I don't understand is how non-existent nodes would be found by the 'associated_files' view and then have the actions_do work on a node of FALSE.
I am going to wrap the actions, context, and actions do lines from this point forward, just in case:

<?php
        if ($current_node){
          $actions = array('node_publish_action', 'node_save_action');
          $context['node'] = $current_node;
          actions_do($actions, $current_node, $context, NULL, NULL);
        }
  ?>

I am currently left with the current observations and assumptions:
- There does exist a bug somewhere in drupal core that allows nodes to be created without titles or more importantly without content types.
- Not only is drupal allowing undefined content types, but so is the database.
- There may be a bug in the actions_do() function that allows potential misuse (as in my case) where $current_node == FALSE when actions_do() is called.
- There may be a bug in rules scheduler that somehow allows some number of broken nodes to be created during cron job executions.
- The number of broken nodes created is different each week, ranging so far from 2 to 14, when nothing except package updates & security fixes have changed on the system during the week of observation and study.
- This is suspect to be a workflow issue as well.
- I wouldn't be surprised if I am overlooking something very simple.
- I still do not have enough information to guarantee any of these observations let alone stand firmly behind any of them.

Other things that came up that I am mentioning for information purposes:
- when attempting to view a broken node I get the message:
Invalid argument supplied for foreach() in /var/www/html/sites/all/modules/cck/modules/fieldgroup/fieldgroup.module on line 566
- when attempting to edit a broken node i get the message:
call_user_func_array() [<a href='function.call-user-func-array'>function.call-user-func-array</a>]: First argument is expected to be a valid callback, '_node_form' was given in /var/www/html/includes/form.inc on line 366
- The rules Log to Watchdog text-field is too short and I have had trouble putting in tokens and php snippets to help produce logs in an attempt to discover the problem.

I am trying not to post such a broad and easily hijackable bug-report in the potentially wrong project, but this problem is difficult for me to identify; I did not want to leave any information out.

Please feel free to re-assign this issue as an issue to another project if it does not belong here or is more appropriate to report elsewhere.