should the Main module's $VERSION equal the package's version?

The scheme was mostly used for C and/or assembler based libraries, so we didn't really have the same concept of separate package and module versions. The nearest thing to a package version would have been the release number. In essence this was just the major.midor numbers with the minor (always 00) dropped. New releases were made each time the midor number was incremented.

Individual clients may be given an an .zz build of a particular file (possible because no external nor internal interfaces had changed; so interfile compatibility was ensured) to solve a specific problem as required, but there was no new release made until a new midor increment.

In effect, the latest release would be 3.2(.0) with some customers having one or more files that might be 3.2.xx (99 >= xx > 00) to solve immediate problems between releases. Pre-release betas usually went out to a limited set of customers and got numbered 3.2.90/91/92 which then became 3.3.00 at release.

Applying this to Perl packages, I would use the same scheme. CPAN releases being XX.YY(.00) with "internal" developments incrementing zz until it becomes time for a new CPAN release. When a specific users reports a bug that need immediate fixing, only increment the zz number and send them the interim. You then note the fix on the bugtracking system (along with the full xx.yy.zz number) but only send it out as people ask for it.

If the frequency of requests for upgrades to a specific level rise above a trickle, then it worth doing a new CPAN release--once you've had feedback (or a lack of negative feedback) from the users who are already using it.

Note: That's just how I would do it. I don't have any CPAN/OSS packages to maintain, so the reality of that environment may be completely different to my experience of in-house and paying customer work.