First: I am not your bro!
Second: They did code it the way it is to specifically prevent what I just said.
I don’t come here to the forums to make stuff up. If I ever claim EHG said or did something it is confirmed in some way or the other,. If I am not sure, I would clearly state that.
It is not random, it is a specific algorithm.
On the same skill setup, it will always remove the same skill point.
No, it doesn’t. It uses an algorithm.
The fact that it does is information that came directly from the devs.
That was the case previously. Seems like they broke this in one of the recent patched.
To be fair, it never did this for me, so I’m guessing it broke with 0.9.2.
I’ve been having the same problem from launch and it never blinked red for me.
Well, their solution is bad, because most players are not looking to break the skill tree by allocating things that will make taking +items off bug things out. Maybe they should just fix the bugs with their skills and +level instead of making us level them up over and over?
Also, suddenly the reasons have changed now you actually bring the devs into it. First it was “helmet swapping is broken and shouldn’t be meta” now it’s actually something that makes sense lol.
Completely baffling to me that I can switch items mid-combat with no penalty, but I cannot casually switch helmets without relevelling my skills.
I don’t know, maybe.
I never needed this function anyway, because I know all my points spent and I don’t need to know which one was removed, so I guess I never paid close attention.
So I can’t remember sicne when it doesn#t work anymore.
But that should definitely be reported as a Bug Reports
this skill thing is probably the single biggest annoyance I face on a daily basis (first world problem, lol). esp for the scurrile hat. for whatever reason the AI picks the summon extra pets node and it bricks me until I fix it.
I did this yesterday, and it blinked red when I opened the skill.
Note: it blinks 3 times, then stops blinking. Scan your eyes fast, or you’ll 100% miss it.
Except it does. The list wouldn’t include the last 3 skills, it would include ALL skills. Your respec of Skira’s Gambit 1/2 would not remove it from the list of 23 points, it would remove only point #23 from the list. When you went to put back on the +3 Fireball it would add Skira’s Gambit 1/2 back on because it’s on your list of #1-#22. Everything would be added back EXCEPT #23 Igneous Force. So yes, problem is solved.
Except you didn’t. Because you clearly should have spent more than 10 seconds thinking about it.
Did it a few times after your comment to test it out. Especially looked out for any red blinking.
Where is it? I actually can’t find it or any other indicator of the skills removed.
But… it already does allow it this way though?
The arbitrary random removal of points without automatically refilling them back when getting them again has no mechanical function at all.
At best it’s a hassle, you’re nonetheless at the same stage of the game as before, your power level hasn’t changed.
So it already allows switching out 2 different items with the same skill bonus without any downside to it.
It has no function.
The only argument there is would be that it can work as a extra detriment for quick-swapping equipment… but even then that’s moot. It would be a mechanic solely based on frustration in design. Meant to feel bad. That’s something which PoE does and it’s an atrocious design-choice.
Using frustration as a friction mechanic outside of a challenge to the player in some way has to be avoided. The only time it should ever be implemented is when there’s absolutely no other way to handle an issue, which means nobody has yet come up with one simply. Which is not the case though.
You currently do get unintentional free respecs this way though. Since the removed points follow a fairly nonsensical algorythm it allows to lower the amount of points in some nodes without breaking connection, giving you the option to respec into others instead you’ve never chosen before.
It’s actually the opposite of their design philosophy, so it could even be considered ‘a bug’ in the current state.
No, it doesn’t, give me a precise example for that situation to happen. Because the removed node is not deterministic it’s the exact opposite of what you’re claiming since it offers a way to put points gradually further away from the initial setup if ‘abused right’.
Weird how you only mention that after an example broke the version you wrote in your OP. 
Retconning your idea after I pointed out how easily it breaks doesn’t mean I didn’t break it, champ.
It doesn’t matter what I have to say about it, though. Mike already said this doesn’t work, had you bothered to read what @Heavy quoted to you:
You’re proposing an intensely obvious idea. They thought of it already. Time for you to throw in the towel.
As already mentioned, this seems to be bugged for some reason. It is intended to blink and did unti la certain point.
I am sorry, but if you still don’t see or understand how the system would be abuseable without this algorithmic point removal, there is nothing more to discuss here anymore.
We explaiend it earlier and the thread I linked explains it even better.
First of all, the answer there has a form of sense behind it… but is illogical.
The deterministic removal of the last points and automatically re-allocating them when putting on an item after does take care of all the issues explained since you don’t have any free points after all and manual de-spec still makes you loose those points, not allowing to re-allocate them accordingly into building differently.
The argument specifically stated ‘If it remembers the point and you put it off and on you can re-spec into the different focus’
Which… No, if the point is automatically re-allocated it cannot
Which is the whole point of my argument that deterministic removal and re-allocation is a better solution of done properly And obviously If not thought through properly like EHG did there it’s allowing exploits in
So, I fell into this earlier as well with:
As you can see here.
It doesn’t allow for 2 Options but solely for the second one.
Why?
Because it handles that exact exploit mentioned by you and in the other thread.
So no, I can’t see or understand the problem given the suggestions and information provided in both threads, since the premise with those adjustments mentioned in this thread is an entirely different situation then what you’re referring to.