The main problem for me is that the

> configuration file lacks a formal syntax specification

IMHO it's too dangerous to be simply done with a fancy regex.

You need validation to catch wrong assumptions and errors in the input.

For instance it's unclear

• if entries are unique?
• if entries need to be ordered?
• how many nesting levels are possible?
• if indentation matters?
• if "random lines" are #comments or "unknown" entries or just junk?
• if there are errors which didn't show up yet
• the quoting matters

I'd personally go for maintainability over speed then.

Like writing an iterator which returns each "VIEW" as a nested data structure.

Like this you can find and report errors and create a tidied version.

Actually it's not too difficult to define your own grammar as a DSL of subs

my $iterator = 
    block
        start => qr/^VIEW \s+ (?<name>\w+)/x , 
        stop  => qr/^END_VIEW/        ,
        hash  => sub {
            entry "RECORD";
            group "FIELD", 
                array => sub { 
                    entries "FIELD" 
                };
            entry "INTERVAL";
        }
    ;
[download]

group() would be a special case of block() with

start => qr/^ \s* FIELD \s+ \( \s* $/x , 
stop  => qr/^ \s* \) \s* $/x,
[download]

Inside those DSL subs I'd use an nextline() iterator, which does single readlines and handles empty lines and comments and returns undef if the stop condition of the upper level is met.

And you might consider using a q_entry() sub for automatic unquoting of "quoted" entries. hence you are free to dynamically adapt to unknown conditions.

NB This is untested code, I started to implement it but don't wanna spend my free Sunday on it, sorry ;-)

HTH! :)

Update

if you wanna go this way, I'll share more insights.