Upon one node creation, populating a node reference by creating a new node of another kind and assigning it to the proper field, with proper ownership

Hi and welcome to Rules! I hope you will find more rewards than frustration. :-)

Here is some help along the way:

-1-
Adding references to the profile node can be tricky. As you write, the normal CCK widget won't accept tokens.
The way to do this is to use PHP, which requires you to activate the PHP filter. Once activated, you'll get a form to write PHP code for the entry. You'll want something like this:

(Where $new_node is the machine name for the node (counter card) you just created.)

Furthermore, you might have to save the new node in order to give it a nid. There is a Rules action for this available – and be sure to tick the box "immediate save", so the save won't wait until the end of all the actions.

-2-
Yep, you can hide the form by using Rules Forms Support. An alternative and more common approach would be a custom mini-module that implements hook_form_alter, but I can't really say which of these approaches that are best.

-3-
When creating the new node (counter card), you'll have to set which of all the available user objects should be used as author. The author of the profile node should be available (and must be the user the profile belongs to) – if not, run the action "load node author" to get it into rules.

-PS1-
I don't really know how Autocreate Node Reference module works. Sorry. :-/

-PS2-
The PHP code to get the proper node reference is more or less necessary in this case, and there's no good way of removing it from configuration. If you really want it in code, you can export the rule. (That would enable version control, but you'd of course still have PHP in your database.)
I don't really know how to build modules, but you'll only need an extreme minimum to implement the hook_form_alter mentioned above. The Examples project at d.o should give a sound start if you want to see examples of module code.

Good luck!
//Johan Falk, NodeOne, Sweden

Hello again!

The actual name of the $new_node variable is set when you create the new node – there are fields for setting the label and machine name for the new object. It should be visible in some PHP hint box on most action settings pages, along with any other available objects.

A general way of finding available variables is to use

in a field that accepts PHP. (This uses the dpm() function, which is available if you have installed the Devel module – a nice help when you build sites.)

I agree that mixing configuration and content is a problem – as do many other Drupal developers. Drupal is moving towards a more clean cut on data, but there are many problems that have to be thought through first – what is content on one site might be considered configuration on another, depending on how it is used. One of many ways to perhaps solve this is to use the Features module, which can create mini-modules from the configuration of quite a few modules (which effectively moves the configuration to code). Features is still far from perfect, though.

I colleague of mine is doing development on the Deploy module, which can do some really cool stuff when it comes to staging content.

Good luck!
//Johan Falk, NodeOne, Sweden

I circumvented the control about the code box with a simple return (dpm(get_defined_vars()));

What appeared when I created a new profile node is dumped below.

What seems apparent is that the node contained in the variable new_fcons_for_profile does NOT seem to have a nid even after the save step. The save Step (2) works because the node is in the database at the end of the rule execution (and the immediate save is checked by the way) but the referring variablenew_fcons_for_profile does not seem to be updated with the new state of the node and especially the nid.

And since it does not have a nid I can't "reload" the node in an intermediary step because I have no real "handle" on it, the nid being the unique and only identifier on a node (or the vid but it does not apply there)....

_{Reminds me then those old timers forbade me to EVER have treatments in a database (trigger, stored procs, auto inc fields) because it introduce inconsistencies of state...}

After fighting a lot I was not able to make this work.
The node seems to get a nid but the "rule variable" seems not to have a hold on the saved node and so not get the nid. It stay in its unsaved state basically.
Hence I kept having php error in my logs because the $new_fcons_for_profile->nid was substituted with something wrong, probably blank and rendered the php invalid.

I had to understand than the php code is not "php" passed to eval but a bit or a lot massaged by the rule module, something I find way to heavy handed as explained above. for instance It checks you have only a "return statement" which prevent all kind of debugging and severely restrict the logic you can put in the php.

On the other hand It took me time to figure than the TOKENS are available and substituted in the "php", something not completely natural for php code and absolutely not stated in the page.
So I spend lots of time wondering what was the use of the Tokens since I were not allowed to used them in the auto-complete fields (a place where it would have made sense), until I figured I could use them in the "php" box.

To achieve my goal I had to trick the engine with another module "node backreference module " http://drupal.org/project/backreference.
I configured the module in the CCK page of both types to have fields pointing to one another (to the profile from the "scorecard" type and back), and linked them up in "node backreference". Then since I create the "scorecard" in the rule, it does not have a nid has stated above but the profile has one, since the rule is activated "upon/after save", thus I can assign the profile to the new scorecard proper field and the module create the reverses link from the scorecard to the profile. I basically do the reverse of what I intended duplicating information a bit, but in my case having both link makes sense, even if I would love to not duplicated information, something that may bite me down the road.
I suppose the backreference module is able to do that because it is triggered after the "scorecard save" action when I assign the fields and fetch its own view of the "scorecard" node thus getting a nid.

These inconsistencies and out-of-sync multiple views on a node are a plague of drupal and a serious blow to reliability and integrity. And a huge waste of time for things that should be simple.
Since it is core to Drupal way of doing things I don't expect it changing soon, but maybe the rule module should reload the data of the node after saving it, to ensure it has up to date things. I say reload the member data, not the node, or we'll have again another inconsistent copy of the same node in memory and some variable pointing to the old one, etc ...
I understand it is a though problem though.

I hope this trick will help people that need to have 1-1 relationship automatically created.

I will also pursue the issue of how to do that programatically since it should be more efficient than with rules and much more portable through staging.
I am pursuing the issue with some kind folks here http://drupal.org/node/812484 in case we achieve something

Ho ! and rules miss a condition that knows how to check a field (being base or CCK) is NULL, would make rule much clearer and support the case of cck3 multiple fields being empty or not. ;)

Thanks a lot for your help itangalo