Naturally, when the link from A to B changes its meaning, A would like to know about it so it can update itself. A couple problems immediately present themselves here. First, since most semantic meaning requires humans to understand it, a human being must maintain the link structure manually. Secondly, if B is malicious or lazy (AssumeStupidityNotMalice), and consequently doesn't update A, or there is no fault-tolerant mechanism to update A, updating alone isn't sufficient.
Given that certain countries consider linking to illegal content accessorizing a crime, this can be a serious problem.
Since this is a social problem, a CommunitySolution seems appropriate. WikiWikiWeb uses extreme PeerReview and BackLinking to ensure content isn't being swizzled without correcting the back links pages. A lighter-weight CommunitySolution is used on WikiPedia, which tries to ensure that, upon moving content to a new location, that a prominent link remains from the old location to the new location. This allows the resulting ContentSwizzling to be fixed lazily, and makes it obvious to the reader. See WikiPedia:Wikipedia:disambiguation
Another approach is to hold all content immutable. (I think this is the idea behind TransCopyright.) If your wiki has a full VersionHistory then you can link to a specific version of a page, and that version can be made immutable even if the current version is dramatically different.
However, one can't hold a content stream immutable. A radio broadcast is by definition constantly changing. The announcer could all of a sudden denounce all dentists as mentally deranged - this actually happens. Consider TedRall's editorial cartoon, syndicated via Universal Press Syndicate, that automatically appears on the New York Times website. It swizzled, at least in terms of popular approval, by defaming the widows of the World Trade Center disaster. While it's arguable whether or not this was worth the outrage it received, the New York Times was sufficiently moved to retroactively censure it.
See Also: ContextSwizzling, MeatballOpenQuestions.
Another approach is to hold all content immutable. (I think this is the idea behind TransCopyright.)
You can still swizzle the content with TransCopyright for two reasons, one technical, the other legal. Technically, the reader still downloads the material from the original publisher, so the publisher is free to change the bits as she sees fit. Legally, the copyright holder has the right the modify the works that he holds as well. You can also apply TransCopyright to a radio broadcast that is (by definition) constantly swizzling in some respects.
To the technical aspect - the notion of a "link" could be extended to include a checksum (md5sum is probably ideal out of currently-existing algorithms) of the linked-to data. Thus the reader would know whether the bits being retrieved from the original publisher were the ones the linker intended or not.
But consider what happens when you correct spelling mistakes. Or the radio broadcast. Inevitably, like most of the Internet, the best way to fix errors is to let the reader fix them for you. If the reader detects something amiss, they should be allowed to remove the link or somehow preface it with a warning. i.e. The Internet ought to be made of wikis. (Wiki:HaHaOnlySerious)
Annotation software is one way to allow the viewer to attach a warning
Technically, the reader still downloads the material from the original publisher, so the publisher is free to change the bits as she sees fit.
IIRC, in Nelson's Transcopyright, one links through to a specific version of a text. If it is subsequently changed, a new version appears, but the text is still linked through the old version. The publisher can (theoretically) change the text of that version, but not without subverting the whole system. --DruOjaJay
Another solution is to just ignore it. Solutions like holding all content immutable sound far worse than whatever minor nuisances have come up due to ContentSwizzling.