Sorry that this conversation is going in circles. At first, I was talking about the culture of migrating to a new system when it supports ~75% of the features (by importance) of the old, rather than closer to 100%. I would find it reasonable for some team to judge that RSS support is not in the crucial 75% (and its lack would not constitute production breakage); clearly you disagree. That's fine.

As for the rest, I was just explaining the general idea of a production freeze. If you're going to stop trying to make changes by a certain date "to be safe"; then that's the freeze date. Equivalently: people keep trying (and sometimes rushing) to do things until the actual freeze date. The date is early enough (quite a bit earlier than Dec 24) so that there's still enough time and people left to fix things or roll back, if there are genuine emergencies. This replaces the risk of production breakage with the risk of embarrassment/questions from asking for approval for an emergency fix during the freeze period, so people will still only do things they're fairly confident will be safe. Anyway, none of this is relevant unless lack of RSS support is considered a production breakage, which is the very point of disagreement here.

Sorry about the "few weeks / months" comment; I was editing it out while you were posting your comment. But yes, when deciding whether something is a blocker, it's safer to assume that it can take indefinitely long (until it actually exists), even if you think (or have been promised) that it will be quick. It's the difference between taking the mean versus the 95th percentile of the distribution of time estimates.