There has been a lot of discussion about this icon on stack exchange and others and it seems the general consensus is that the floppy disk symbol is a metaphor for “save”, in the same way as the old style phone icon used in your mobile phone is used for “call”. The fact that nobody uses floppy disks anymore is irrelevant.
Example discussion on stack exchange:
First of all I didn’t throw it, but carefully placed. Second, that was a self moderated version of what I actually thought about it. Hang in there buddy, don’t be so distraught!
The first thing that you learn after having kids is that the final result of cleaning the kitchen is not necessarily a function of the amount of time spent by them doing it.
I like the new icons used for the tools in EESCHEMA and PCBNEW - mostly.
The “Down arrow” for Add symbol is somewhat strange, as it’s the only item in the set with an additional graphics symbol (i.e. no symbol for Add wire, Add footprint [pcbnew]).
So to make it consistent, I’d leave out the “Down arrow on the badge” part.
The Floppy symbol is fine to me (as a Floppy), however it’s a bit distorted floppy (huge notch, smallish slide cover). But that’s aesthetics only, no issue with usability whatsoever.
Now I’m not sure if I like the main icons. Changing tint of EESCHEMA/SYMBOL EDITOR was a move in good direction, the Gerber viewer now is more distinguishable from PCBNew; although I’d prefer adding some symbol of Magnifying glass/similar as a reference to “inspect”.
Most problematic are the icons assigned to particular files in the project, and that’s IMO the area where the new set could be improved most. These are the icons that don’t have fixed positions, so are most important UX-wise. Coding with color (tint) could be a solution for most of us. But we should not be expected to stare at the small pictures to know if the particular file is a schematic, board, bom or any other part of our project.
The uprising is brewing. The request about the camo icons are starting to pop up on the Github with alarming speed. Here is another example of this grassroot movement
[Edit:] #6699 (linked by ArtG) has already been closed (old icons are not coming back). At the bottom a request has been posted to add specific requests for improvements to #6668, also linked below.
This issue on gitlab currently has 12 upvotes and 0 down votes, which is quite a lot for a 2 day’s fresh topic.
Thank you to everyone who has taken the time to provide details that need adjusting. We worked on the details out of tree for a couple months but it always looks different when you merge graphics and we are working to account for those differences now.
If someone wants to redraw the icons with alternate colors, that is great. We may be able to support icon packs in the future that would allow you to swap them in to meet your specific needs.
That said, we cannot continue to use our old icons. Some of them were derived from GPL sources, some were unlicensed and some appear to be derived from commercially-licensed icon packs. Legally, it places the project in jeopardy, and whether or not those licenses are ever actually enforced is not material. Before we redesigned the icons, I spent a couple of years tracking down the origins of the icons in our original icons and contacting the people who checked them in and designed them to attempt to get the licenses sorted. We were able to get proper licensing for about 60% of the 480 icons. The remaining 40% were unknown. Either the designer did not respond to my inquiries or did not recall where they sourced the icon.
I will note that virtually this same conversation happened after the 4.x icons were updated for v5. Change takes time to adjust and I hope where you find specific concerns that you will add them to our issue tracker
It’s definitely a new record. It’s really interesting how much heat a non-functional change has raised.
BTW, I left a (hopefully final) comment on #6699. I hope it explains enough to make it clear why the old icon set won’t come back and why the new one was necessary.
EDIT: now Seth explained it in detail with authoritative knowledge.
I find it quite logical that making KiCad Icons non functional kicks up a lot of dust.
Take for example the last screenshot I made:
The old icons for wires, busses, different labels types, etc. were a perfectly clear representation of how they look like in Eeschema. Now half of them turned into mostly grey blobs, and colors for wires and busses do not match Eeschema.
My bias here is that I have lived through exactly this kind of change before, so it’s exceedingly hard to suppress the feeling that users are being forced to like the new icons at gunpoint (“this is what it is, no way back, no alternatives”). There are countless reports from users which were rather upset about such an invasive change: https://forums.autodesk.com/t5/eagle-forum/eagle-8-0-0-icons/m-p/6820217#M190
This was about the time when I abandoned Eagle in favor of KiCad, just to relive it now.
There are two things I would wish for:
Introducing v6 with the words “we had to go a step back and then ran out of time to recover” is not great. Surely it can be understood given the legal gravity of the icon issue (if communicated up front!), but it may damage trust in the overall quality and in being considered as a user.
I’m sure that if (icon packs are) implemented, users will engage a lot more in the KiCad look-and-feel, and results can be harvested and consolidated more easily. With this current move, KiCad will take a hit in its existing user base.
You do realize that the icon pack is not final, right? What will end up in v6 and whether it will be a step back in any way is yet to be seen.
And it’s not like devs are not listening to feedback and just shoving things down users throat.
Several icons have already changed in the last few days.
For example the icons in the project manager have gotten some color, and I see that the icon for annotation has changed to “R42” 
It remains to be seen how much of the feedback in issue #6668 gets implemented.
I initially thought the same as you but after a few hours using it I prefer the “thick” and “thin” lines much more than different coloured lines. There is also some basis to this: eeschema allows you to change colours for busses and wires. Green doesn’t necessarily need to represent a wire anymore.
Also, in my office we only print in monochrome, so colour for busses and wires makes no difference: thickness does.
I do try to be realistic with what is achievable in the remaining time, and yes, icons not being final is what I implied in my statement above.
If it took months to get to this point, I would not want to ask of those involved to rework most of the items again in an effort to please users. The new icons would even need to be better than the old ones to break even, as they would have to make up for the inconvenience of re-learning the visual connections.
As for the devs, I was not aware of this forum thread smoldering for a bit before I opened the issue and found the “blame-and-silence” approach in 6699 disturbing. I only discovered the new icons earlier, so I’m now catching up with this thread and consider closing the issue an ill-advised measure to contain criticism on gitlab, but I still think users should be able to use the icons they’re used to without spending days to set up a build environment.
I humbly suggest you take a look at the last 3 days of commits, and see how many updates @Seth_h has already made to the icons, many of them in response to user feedback.
User feedback is clearly not being ignored…
Would it be feasible to temporarily put the old Icons back, and postpone the update of the Icons and combine it with the GUI change for configurable toolbars etc? I think that is expected for KiCad V7.
I might have to. I didn’t update for a week because I had to finish a project without further interruptions through nightly surprises 
I can’t see how that is possible, given that the project has already identified this as a legal risk.
GitLab is not the right venue for venting unhappiness at the devs.
Your issue requested that we allow you to use the old icons. Unfortunately, we can’t do that, so I closed that issue. I’m sorry you felt silenced by this, but we do not want to keep issues open on GitLab that cannot be implemented. I really do encourage you and others to open other issues requesting changes to the icons. Reverting back to the old ones is not possible, but continuing to evolve the new ones is definitely possible and will continue happening.
I still wonder which of my statements in 6699 one would classify as “venting”. By locking the issue, you also prevented others from further commenting, which has nothing to do with focus and everything with control. With “measure to contain criticism” I was also anticipating others chiming in, so I can understand a certain incentive to close the thread before it departs from the actual issue. I would appreciate a way to use alternate icon sets though, and these might just happen to enable users to use icons that look a lot like the old ones without liability on the side of KiCad.
I didn’t think you were venting, but your issue was encouraging others to vent in the comments.
The problem is that it doesn’t matter how many people chime in saying “the new icons suck, please revert to the old icons!” We still can’t do it, so we can’t make those people happy. The more people see such an issue, comment that, upvote it, etc, the more people get “misled” into thinking that this is an option.
The only way for us to make you and others happy with the new icon set is to continue iterating on the new icon designs.
Allowing custom icon sets so that users could put their own icons in and not worry about licensing could be opened as a feature request, but that wasn’t what you put in your issue.
