This brings up one of the issues I have been trying to resolve for a very long time. My problem stems from the need for very long file names. Sorry for the discussion divergence, but this feels like a meaningful place to bring it up.
Unfortunately the problem with very long file names is that there is a character limit. But, unlike any other feature in Obsidian, the actual text within links can actually be updated when that file is. Without having to rely on embeds or fiddling with alternative link display text via | characters, the ability to simply rename a note and have the actual link text within notes be automatically updated is a very unique and powerful ability. But, it is heavily limited by note name length limits.
Especially now that Obsidian has this option to show note names inline as H1 headings, I see potential for some functionality that outsmarts the character limit and lets you compose a few hefty sentences right in that H1 heading and have it auto update all links to the note regardless of the actual note name. Like @AlanG said “The filename is irrelevant.” Of course, he said this in a different context. Anyways, after writing all this out, I decided I will simply create a feature request so as to avoid further distracting from this discussion. Note name length unlimited
Edit: Below @alain1405 kindly suggests using aliases. However, aliases are simply used to help find the link within the auto-suggester, and they automatically add the | character so that the link is displayed as alias. The issue with goes back to my whole goal of being able to update the note name and have the change update all instances of links to that note. Aliases do not update when they are changed. There are multiple discussions about this in other threads. I’m right there with you. This would be an elegant solution if it updated. Anyways, here’s a link to one topic that clearly describes this: Automatically update links when aliases are renamed. I appreciate the response, I will mention it over in my new request as a possible workaround that would rely on another feature request being implemented first.
Thanks.