If you use this code gets quite short.

My code for B was also 300 lines, but it's 200+ lines of building HLD and doing generic HLD queries and a fairly standard segment tree (set/add/get_max), the part specific to this problem is maybe 30 lines.

The contest lasts 5 hours, so it's not all that much.

Fun fact: $$$t=2$$$ wasn't originally intended to be in A and none of us saw the simple solution for $$$t=1$$$ until about 2 weeks before the contest. Even then, it was found by simplifying a much more complicated solution. The intended solution was always about supporting arbitrary removals and keeping/updating a set of removable cells, so we changed it (added the $$$t=2$$$ format) to make sure only those solutions would pass. Of course, the input is a random permutation of some valid order (yes, I know it's better to choose the permutation more carefully).

I didn't find $$$t=1$$$ all that easy to find, but easy enough to "find" by accident. Turns out it really was pretty easy and it's a good thing I pushed for not making it the 100pt solution...

My code for B was about 150 lines, it's easy to think but hard to write. I used edge based divide and conquer, tree chain dividing and binary index tree. I wrote and debugged 2+ hours, I felt desperate. (My English is poor, don't care about my English grammar mistakes)

Trust me, there were more out-of-syllabus proposals. At least HLD is so well-known at this point everyone should be able to do it. Maybe it'll get added back to syllabus soon (it was in IOI 2011). If you can see such a solution, you should start writing code from memory immediately. I don't like it all that much either, but not everything can be skyscrapers.

I had to optimize my $$$|Σ|^8$$$ solution to C in order to pass the first subtask.

I didn't know that could happen. $$$6^8 \approx 10^6$$$ and the inner loop is simple, without even any cache misses.

Subtasks that suggest the solution, or more generally, possible ideas a contestant could be missing, was kiiind of intended and it's pretty common in IOI-style problems in my experience. The other, more important, purpose is that if there's a bug in a full solution, it will still get some extra points. Imho if someone can figure out a full solution just with the help of subtask structure in-contest, that's fine and that contestant deserves the points just as much as those who wrote HLD from memory.

I don't see A as particularly implementation-heavy. If you have the main idea (that you need to write one function to locally decide removability and how to do that), which is the hard part, everything else is quite simple. My code is written for clarity and some efficiency rather than code golf and it has "just" 300 lines.

1. You need to parse the input into a graph with $$$\le 9N$$$ vertices and do a BFS/DFS to find components. There's no way around this, but it's all very easy.
2. You need to write the "update" function. All decisions about articulations and reachability are contained here. It uses graph information: components, degrees, which cells are empty and the graph itself.
3. When you remove a cell, you need to merge components and update the degrees. This is classic union-find. In the process, with the slower version of union-find where you don't maintain a tree of merges, but just merge smaller components to larger ones, you're looking at all vertices whose component changed. Look at their neighbours and run update() for them. Also run update() for neighbours of the cell you just emptied.

You can solve B with the same trick you used on the problem you created!

If you do it this way you can avoid tedious implementation!

https://codeforces.net/contest/1149/problem/C

Aw damn. Probably because I'm in admin mode with no way out of admin mode. I'll try to do something about it.

UPD: Fixed. Now I can see it in porn mode too.

Thank you so much! Just to clarify that we usually choose adjacency list over adjacency matrix since it saves more space, is it correct?

Thx. Nice trick!