Asiasoft's definition of "permanent".

2) It's very easy to tell which chairs came from the event. The ones whose expiration date is exactly 30 days from the day the character completed "Finding First Loves - Day 8" (or w/e the name of the quest for getting the 8th day reward is). It's probably safe to assume that any PB chair which expires between 20-28 April is from this event, but as I said, if you want to be certain, check the quest log.

1) There's no need to fix the quest. They can simply issue notice that "The chairs will be replaced with permanent ones in a maintenance on April 4th. Please complete the event as it is for now." Of course, we'd have to believe them...

The only real technical problem I can think of is that there is no permanent version of this chair in the data right now, so they really don't have any perma PB Chairs "in stock". They can't put something in our inventories that isn't in the data (without a patch).
However, they can get around this by taking a page from Asiasoft's book, and making the chairs "perma" by setting their expiration date a few decades away.

Sure, these are the things that I would do if I owned the game and it was a private venture. However, anyone who works in the industry will happily tell you that there is a piece of red tape that always gets in the way - Change Management. Change Management is the bane of all developers. It is supposed to exist to regulate code changes and additions across multiple versions of a product line. It is there to make sure you are putting things in the right place, etc. But, in practice, it gets in your way CONSTANTLY. With a company like Nexon who has multiple localized versions of each game product they produce, their code management software is going to be locked down pretty tightly. The smallest of changes that might take a few seconds still has to go through the entire internal change management policy. This would likely entail the following steps be followed (adapted from the Change Management policy in my own company):
1) complete documentation of the error and its cause
2) code location and proposed fix
3) creation of a new test instance for version being corrected
4) actual fix coded
5) Fix tested and submitted for approval by the product manager
6) new source distributed to the code base in use by developers of forthcoming content
7) developers determine whether the change alters their work
8) Product manager signs off on the change based on the recommendation of the other development team. If it is a minor issue with big impact, it will probably be denied.
9) Distribution team creates plan to update the product.
10) plan is approved and then scheduled
11) Product fix is put into place and given final testing before re-opening the game to the public.


It's a ton of steps. Worse, though, is that no matter how small the change is, it has to go through all of it. Such is the life of a product development programmer, which I have been for 20+ years now. The issues I mentioned are not technical marvels that cannot be overcome. They are possible excuses for Nexon not to take the time to fix the issue because of the tremendous hassle they feel it will be.

TL;DR - Nexon is likely too lazy or busy to fix the problem.