both use the returned $pos1 ($pos) unaltered when $first is undefined.

Ah! (blush} I oversimplified.

In-situ, the call to f1() is followed by:

        return unless defined $pos;
[download]

Information which makes your reduction very pertinent and holds out the possibility of reducing the whole snippet to a single level state machine.

The block of code in the OP actually sits within a while loop in the real code. What the code does, is takes a string of the form:

{ a => [ SCALAR(0x18bb45c), { a => b, c => d, e => f, g => h,  }, [ 1,
+ 2, 3,
[download]

and pretty prints it like this:

{
    a => [
        SCALAR(0x18bf6a4),
        {
            a => b,
            c => d,
            e => f,
            g => h,
        },
        [
            1,
            2,
            3,
            4,
            5,
            6,
[download]

or like this

{
    a => [
        SCALAR(0x18bf6a4),
        { a => b, c => d, e => f, g => h,  },
        [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,  ],
[download]

or this

{
    a => [ SCALAR(0x18bf6a4), { a => b, c => d, e => f, g => h,  }, [ 
+1, 2, 3, 4, 5, 6, 7, 8, 9, 10,  ], {
[download]

depending upon a width argument supplied--but there is an additional twist.

The code generating the input does it in chunks as it recursively traverses an unknown datastructure. The pretty printer gets fed those chunks (it is called from the STORE routine of a tied scalar), and is charged with pretty printing the (accumulated) string each time it goes over the width limit without waiting for the whole string, or even a complete set of balanced text to accumulate.

The idea is to avoid having to hold the whole of the potentially enormouse string in memory.

I probably should have posted the whole thing for communal refactoring, but it has so many dependancies that it would be asking a lot for anyone to look at it.

Not to mention, that I was embarassed by the code in every respect--except that it worked!