• Your diagram is easier to work with if you print it top-to-bottom instead of left-to-right, so I made that change.
• No hashing needed, as long as it is OK to do linear scans across all your tracks.
• I used first_index() from List::MoreUtils for clarity; it will be simple to duplicate its functionality in C.
• I wrote this code with *no* understanding of what you are trying to accomplish. Whether or not I got it right, please enlighten us on the root problem you are trying to solve (or mathematical behavior your are trying to explore, etc).

Working, tested code, insofar that I grasp the problem:

#!/usr/bin/env perl
use strict;
use warnings;
use List::MoreUtils qw(first_index);

my $duplicate_original_post_data = 1;

my $generation_limit = 99;
my $r1_count_limit   =  4; # 1..4 elements
my @r1_keys = 0 .. ($r1_count_limit-1);

sub pad { map {$_[$_] || ''} @r1_keys }

my ( $R1, $R2 );
if ( not $duplicate_original_post_data ) {
    $R1 = sub {
        my $n =        1 + int rand $r1_count_limit;
        return   map { 1 + int rand 100 } ( (0) x $n );
    };
    $R2 = sub { return 1 + int rand  20 };
}
else {
    my @fake_r1 = (
        [  17,   1,  20,  12 ],
        [  13,  24,  21      ],
        [  19,  30,  31,  27 ],
        [  22,  34           ],
    );
    my @fake_r2 = ( 4, 6, 3 );
    $generation_limit = @fake_r1;
    $R1 = sub { return @{ shift @fake_r1 } };
    $R2 = sub { return    shift @fake_r2   };
}

my $template = "%5s %5s %5s %5s %5s %5s  ->  %5s %5s %5s %5s\n";
my @last_array = $R1->();

printf $template, qw(Gen R1.1 R1.2 R1.3 R1.4 R2 Trk1 Trk2 Trk3 Trk4);
printf $template,      1, pad( @last_array ),
                  'None', pad( @last_array );


for my $generation ( 2 .. $generation_limit ) {
    my @r1_array = $R1->();
    my $r2       = $R2->();

    my @leftover;
    my @new_array = (0) x $r1_count_limit;
    for my $r1_num (@r1_array) {
        my $target = $r1_num - $r2;
        my $slot_to_use = first_index { $_ != 0 and $_ == $target }
                                      @last_array;

        if ( $slot_to_use == -1 ) {
            push @leftover, $r1_num;
        }
        else {
            $new_array[ $slot_to_use] = $r1_num;
            $last_array[$slot_to_use] = 0;
        }
    }

    my @empty_slots = grep { $new_array[$_] == 0 } @r1_keys;
    while (@leftover) {
        die if not @empty_slots;
        $new_array[ shift @empty_slots ] = shift @leftover;
    }

    printf $template, $generation, pad( @r1_array  ),
                      $r2,         pad( @new_array );

    @last_array = @new_array;
}
[download]

Gen  R1.1  R1.2  R1.3  R1.4    R2  ->   Trk1  Trk2  Trk3  Trk4
  1    17     1    20    12  None  ->     17     1    20    12
  2    13    24    21           4  ->     21    13    24      
  3    19    30    31    27     6  ->     27    19    30    31
  4    22    34                 3  ->           22          34
[download]

10   15
20   5
30   35
40
[download]

What is the expected output of the program? Should it just return the new status based on R2 and R1 for each step, or should it build a structure representing the whole process?

Yes I forgot to mention that, the 40 is forgotten. you always pick from the last array in this example 15 5 35.
What is the output, well just the updated status after , let say 10 iterations
sorry, cheers

Then R2 kicks in and generates number 4. After that R1 again produces let say 3 numbers (13 24 21). The problem now is how to efficiently (without hashing) figure out that 24 should go into $array3->third track since 20+4=24, and 21 into first track since 17+4=21 and 13 in second or fourth track - it doesn’t matter.

Obviously, everything in the algorithm and its implementation depends on knowing what the rules are... and from your description I can’t guess.

Certainly, I would implement your solution in C++, not C, if it actually comes to that, because in that language you do have ready access to data structures such as queues, balanced-trees and arbitrarily-sized “arrays” (collections ...), all without having to write them from scratch.   (You have better things to do with your time.)   But if your problem really is small, as it superficially appears to be, it seems to me that you don’t have much of a problem here.

Basically, if you can manage to deal with the problem “in memory,” without getting into page-fault hell, you can actually do things in a very brute-force way and get away with it perfectly.   It is, for example, to say #DEFINE MAX_BUCKETS 10000 and thus allocate a fixed-size 10,000-element array and to have your program (check for, and gracefully and meaningfully terminate itself if ...) that limit is ever someday exceeded.   (As I once read in a macabre bit of source code:   “Dig me up and I’ll fix it then ...”   Ick.)   Given that modern processors execute (at least) hundreds of millions of instructions per second, if you can’t clearly demonstrate that a “sophisticated” solution is mandatory in order to solve the problem in all of the cases that you will encounter ... don’t build one.   Unless you can demonstrate that major page-fault activity might happen, the algorithm is going to execute at the full speed of the CPU ... or the maximum speed of the I/O subsystem, whichever is less.

(Whether, by the way, it is implemented in C++ or Perl... for all practical intents and purposes.   The coders who put together perlguts are gods...)

(It goes entirely without saying that if what you are describing is actually some god-awful CPU-intensive operation for some image-processing or cryptographic application or what-have-you, my opinions here would not apply.   But you knew that already, didn’t you?)