Take a look at how easy/convenient it is to make "old" information available elsewhere.

It seems to me that old configuration information is kept around in the file partly for version control information and partly because it might come in useful later.

In the case of version control, maybe, maybe you can move that part to a version control system like git or Mercurial. This will require support from all users, so that they also know where to look at older versions of the file. Maybe you can put the link to the repository viewer URLs at the top of the configuration file.

In the case of documenting history and/or old/other usages, it is much harder to move this to a different location, as people will likely differ on the terms to search for. In some situations I got buy-in from users using TiddlyWiki for documentation. In other situations, a long (long!) Word document where old topics get moved to the "done" section and current topics stay near the top of the document.

A third approach could be to create your own viewer(s)/editors for the document that hide commented-out lines or that reformat the "current" file with additional comments and maybe can link to relevant documentation etc. - but that introduces yet another tool to the set of tools that the users already have, and will need maintenance.

You are already talking to the actual users of the process, and while the process might be hated by everybody, it seems to already have worked for 40 years. Your replacement of the change process to these file(s) will have to take into account that there are some parts of the existing process that actually work and the new process ideally doesn't break the things that already work while improving the things that are currently preceived as risks or hard.

Consolidating the different files screams for something like version control and maybe a centralized process of changing the configuration file actually used in production. The daily backups are fairly close to version control already and people are likely also familiar with the process of retrieving a good version from the backup. Implementing a centralized process of updating the Master configuration will create a bottleneck there because if the person(s) doing that change are unavailable, no such change should happen. On the other hand, this will create a ground truth and eliminate the different versions of configuration files that people keep around for that one time they had to change that obscure thing.

You are already talking to the actual users of the process, and while the process might be hated by everybody, it seems to already have worked for 40 years. Your replacement of the change process to these file(s) will have to take into account that there are some parts of the existing process that actually work and the new process ideally doesn't break the things that already work while improving the things that are currently preceived as risks or hard.

This is the sort of thinking we've had behind adding some informative headers to the sections. The users can still do what they already do more-or-less BUT we introduce a process that does some reporting on those sections that are 'non-compliant' in terms of the headers the section includes.

Y'see, one of the problems is that the software we're talking about is totally 'closed' and we have no means of intercepting/controlling the input/usage/management of all these sections - we have to use the software to do all that - but there are text files of all the sections that are maintained 'live' by the software... and we can interrogate those text files with our own tools.

So, as far as the documentation of the sections is concerned, we were looking to develop some mandatory/optional headers to be included in the sections, with some application rules... and then our external tools would enforce the inclusion of those headers.

This would mean this current section:

123:
A1=12:MSMA=32:PX=2:
RP=12,23:
[download]

...would perhaps become something like:

123:
; Author: Fred Smith (smithr)
; Created: 12-Dec-2016
; Used by: MODV, MODS in XDR Region
; Purpose: Control the rate at which widgets collapse into wigwams
; Keywords: train, isolated, trim, summer
; Expires: 23-Dec-2016
;
A1=12:MSMA=32:   ; To set-up for the collapse
PX=2:
RP=12,23:        ; ...and into wigwams
;
[download]

I expect we'd supply some sort of template for users to fill-out and then paste the result into the software's text editor/input... and if our tools find something 'wrong' with the headers, it would be noted in a report.

I note that to get these folks to change their behaviour (and to get some management support about doing something to fix one of the problems that's been identified) will be/already is a significant battle... but they need to meet us somewhere half-way if they want to get their problems fixed, I reckon..

Anyway, this is something of a 'side issue', although I expect we'd get some good value out of it, as there are 1000s of sections with no documentation that the users constantly complain about... and get trashed/re-used accidentally.

Still thinking about the suggested options for how to actually manage the sections themselves...

I'm personally on the side of those who prefer clean configuration files, and a proper documentation on the nature of the configuration file which provides all necessary information about things possibly missing in the file which is actually used.

So, since you already have tools which check the dependencies, you could generate a hyperlinked documentation of those sections and their contained items, which could be checked just in case and, in the productive configuration files, just one line of comment for each missing section, according to the config files convention, containing a link to the missing section's documentation.

That way the "just in case" folks have their reference, and the others would see the clutter as having been drastically reduced.