The interesting question isn't the raw number, it's what those 408 lines are doing - it's entirely possible that half of that could go upstream.

For some years, lots of vendors had patches to mess around with perl's default @INC order, all of which were distro-specific and not really generalisable, because nobody had bothered to submit the upstream change that would have got rid of that whole class of patches.

Now, I suspect the reasons for that may have been to do with perl's then rather slower pace of releases, so people didn't see the point when perl5 version 10 was apparently not getting any closer, but just because that reason doesn't apply to chromium doesn't mean there isn't a similarly convincing one for local patches.

It also doesn't mean there -is-; I've always been fond of local patches to software being corresponded with a distro bug and preferably with an upstream bug explaining the rationale; it may not avoid the necessity for the patch but it at least means the conversation that led to it is both visible and involved the right people.

Looking through the ebuild it looks like a decent amount of it is related to keeping it from using bundled libraries instead of the system ones when building. After that it looks like most of the rest of the complexity is related to getting things installed to the proper places.

So, it's of the same order of difficulty as Firefox? Is this surprising?

For a modern codebase, yes.