Nah, it's not incorrect. It all boils down to your port's philosophy. Personally, I'd support both.
If I wanted to take a hard line I'd reject supporting both NRFTL and the new IWADs. Both cross the line to different extents, but sometimes I "bend the rules" for certain things. As it is, I've decided to support the new IWADs (which required the addition of only a small workaround), but not NRFTL (which requires more extensive and far reaching changes).
myk describes NRFTL as "Vanilla compatible" which I find interesting. I don't have a copy of BFG Edition or NERVE.WAD, but my understanding was that it exceeds the Vanilla limits, and that's my main objection to adding support for it. Is that incorrect?
The way I see it, Chocolate Doom serves 3 very different and distinct masters:
1. Map/WAD authors - These guys want to see every hard crash, every visplane overflow, and, yes, save game overruns. They'll want to use Chocolate to ensure that their creation is DOS vanilla compatible.
2. Knowledgable purist players - They want the game to look and feel exactly the way it did 20 years ago, but they don't want their game to crash!
3. Newbies, looking to see what Doom was all about, without hassle, without 150 settings to tweak. They don't want their game to crash either!
So, therein lies the problem. If I were running the show, I'd do the following:
1. Support NRFTL, for Person type #3.
2. Add a "-strict" option, to force all vanilla limits, including savegame size. Person type #1 would use this.
3. Up the limits a la Doom Plus, for Person Type #2.
NOTE: Maybe you would prefer to reverse the default: "-limitremoving". But I would suggest not to - only authors would typically use "-strict".
Yes, that's a big decision, but I don't think it deviates from the philosophy - It would be a port that provides non-crashing original bugs, and a damn close look and feel, even if the WAD has a lot of visplanes. That's a very desirable engine, for a lot of reasons. One would say "use PrBoom[+]", but, Chocolate could keep it's menus, resolution, graphics, etc. original, and avoid "gameplay-deviant" behavior, like Boom specials, etc. Basically, Doom, without crashes, conditional on the presense/absense of the "-strict" parameter.
Even if you didn't want to up the limits during play time, the "-strict" option would give you a place to "park" deviant behavior. Examples: Savegame limit removal, INTERPIC vs. TITLEPIC, visplane limit, etc. That way, it would perhaps become easier to decide whether or not to add support for this or that feature in the future. In other words, I feel that, right now, it's very difficult to decide what to support, because it's "all or nothing", whereas if you had a way to switch between two different ideologies, that would alleviate this tension.
Something to consider, anyway.