Been in the industry over 20 years now, so I am sorry I for not being more specific with my examples here. (I learned this lesson many years ago) But here's some recollections.
In the process of building something if I added say a color picker or a calendar date selector, but the client wanted just a text field. Then the color picker/calendar date selector has an issue with a really, really old browser and I have to spend time debugging it at their request. (again because "young and inexperienced" me can't explain it properly)
My current self would just remove it, and/or explain it will cost extra. Soo 100% of the problems I described above are solved with mature communication that I learned the hard way.
--Features requested vs features built--
A client will ask for 100 features up front, we build 10 and by the time we have an alpha, he bails on 90 of them, and adds 20 new ones. Of those we bail on half again. This is so normal that I now bring this up at meetings to help us prioritize development.
I have had very long term clients ask me to remove something, then later ask "where did that feature go?", ha. I have to laugh at this, and I explain to them "I don't remove features without written request, if you want me to spend time looking up why this is removed (likely from an email) I can do that..." But they never have me do this.
I have built extra templates/views, sorting features, even tools to add/remove things the client didn't want users to have access to, so I had to delete them. (no one would pay for a toggle to disable a feature they didn't request, hence the delete on my dime)
One client even went so far as to say he didn't want _his_ clients (it was a CMS for web sites) to see how easy it was for him to build sites using the software. (his clients had access to the software for content maintenance)
I had built an LMS (Learning Management System) with a group once (again, I was young and eager to impress) and I vaguely recall adding some features for working with quizzes or something, but because I had at least 2 PhD's on the team, that mightly protested something about "that isn't how that process is supposed to work...blah blah", that I had to remove it.
I was the sole developer on a project with at least 2 designers and 6 (yes 6) project managers... ugh. They asked for the dumbest things and I would protest a little by building it a "smart" way that wouldn't piss off the users. But I had to revert everything and try to hack my way through making their overly complex visual designs work on web 1.0 _and_ support super old versions of IE at the same time... because project managers know what users want best.
--Design alterations on the fly--
When CSS was still immature, and many layouts were very hard to build, I made some complicated things in a mapping program that insurance workers would use to map out and plan routes and such. Google maps was very new (so maybe 2006/7 ish) and we were building on top of this. And I would build layouts that I thought were ideal for users, because the client was just the business guy he left the design work up to me. And I had to rework the design a few times. Even after I had already specced everything out, and the client agreed.
The lesson here was that the client blamed me for bad design decisions based on our poor communications. I had visually laid out the entire app before building it, but because we kept redesigning the visuals, doing a visual spec for each change was overwhelming. So I just made changes sorta willy-nilly based on meetings. And the client would come back and call a design decision a "bug" so he expected me to fix it for free... ugh.
--Verbal change requests--
I had a client freak out on me (he had a temper and I was young and didn't have courage) claiming I had "told him to do X & Y" on a phone meeting 6 months prior. And therefore I was on the hook to fix it for free. I don't even recall what it was, but I remember the verbal bashing I got.
This is where I learned to stand up for myself in a mature manner. I told him I don't recall saying that, and that I make a point to only make changes like he was describing in writing. And I pointed out that it was unfair and unreasonable to expect me to remember what I said on a phone call last month, let alone 6 months ago. And this is one the reasons I get do changes like this in writing, to avoid these exact conflicts.
He was angry, and I weathered the storm, but it was a valuable lesson. Not everyone is nice and reasonable, but you may have to work with some people this for a time. And having a good set of communication and process rules keeps you from getting blamed for something that isn't your fault.
This is getting long, but I didn't mean to imply "support" was some huge on-going thing for some giant feature I had spent days on. But more edge cases that the OP was bringing up, but seriously impacted my motivation on the work and affected my relationship with the client.