Our problem: usual spread is four seasons over twelve months. Seasons are not months 1-3,4-6,7-9,10-12. [...]
Year will start in what is now December, which will be renamed January. New Year will be on January 1st, Christmas will be on January 25th, and so on.
Sorry, but if you want to make seasons match months, you need to start with "January 1st" on[1] what is currently December 21st.
In fact, weren't various historical (and non-Western contemporary?) calendars originally based upon a "start at the Spring equinox", or another of its sibling quarter-points?
Anyway, the way to go is pick a given solstice/equinox (or its diametrically opposed one, for those in the other hemisphere from your own reference), these four
instances in time being the least arbitrary points. Use that as the start of the year, or at least so that the midnight-to-midnight cycle[2] containing that instance is the "day of the new year" at whatever Prime Meridian you're choosing and having the rest of the world (that cares to follow the system) adjust according to their time-zone (so may have that moment in the day before or after, depending on how it all happens).
Months. Based (at least originally, and now only roughly) on the cycles of the moon. A 27/28-ish day cycle (according to whether you measure absolute or adjust for Earth's rotation). You could take the point the moon is at at the start-of-year moment and choose that to be your month-boundary for the remainder of the year. Again, depending on how you're measuring it, you'd end up with either 12 full months and a thirteenth 'spare' month at the end of the year or 13 full months and a smaller 'spare' one in 14th position. Depending on which your triskaidekaphobia might feel most comfortable with. This spare month would take up the leap-year slack, as well.
The spare-month would be useful as a holiday season, perhaps on top of the (not on month-transitions) other three 'quarter-points'. Easter might need some minor renegotiation and re-assessment, for those that don't maintain the current Gregorian/Julian calendar versions[3] despite the change in the civil calendar, but existing days such as December 25th would map decently well to a particular day in the new calendar in the first year in the new system which wouldn't be noticeably incorrect between the systems on any future year. New Year's Eve would be the worst affected, except that it's the last day of the year, regardless of Leap Year and other enforced astronomical variation. (Anything that happens to sit on such a date initially adopted as that day may end up being the new Feb 29th and not reappear every year, or else find another day buffering between it and the new year... If we don't start the new system until a year that is not going to be a "Leap Year" example, only new events (births, etc) get caught out. On the other hand, actively starting on one that is means that people born on 29/Feb/xxxx under the existing system get a day that they
now get every year!.
Anyway, now we have months re-tied to the moon (and, if we use the start-of-year state of the moon as the month-boundary point in the phase, might call each year a "New Moon Year" or a "Full Moon Year"), we can rejig the weeks so that the first of every month is the same day of the week, and the month-end has the same flexibility for week-length as year-end has for month-length. We might as well stick with seven days a week, as it would work well, although I can see four-days-a-week working. Or (if you know you're going to have a partial week anyway) eight.
It'll all make the successor to Zeller's Algorithm a lot easier to work out, of course. In a still seven-day-week system, you'd have: "What day is <Firstmonth> the 7th, in the New Year 41" "<SeventhDay>!" "Correct. What day is <Thirdmonth> the 13th, in the New Year 39" "<SixthDay>!" "Correct. What day is "<Ninethmonth> the 24th in the..." "<ThirdDay!>" "...New Year of... Correct. What day is..."
(All this give or take some probably forgotten details, anyway.)
[1] Or within a day of, given the vagaries of celestial mechanics and where your time-zone lies around the Earth.
[2] Assuming you don't want to change to dawn-to-dawn or midday-to-midday, but being that we're not nocturnal it still is best to keep the day-change based around midnight, rather than 6AM/PM (local time, disregarding DST or other irregularities to the local clock.
[3] In reality, it'd still follow roughly the same back-and-forth cycle, except insofar as the G/J calender versions (or, rather, ones based upon astronomical instances hitting a different day in the East than in the West) currently vary.