A few readers wrote in response to me sharing Panic’s blog to say that they witnessed online publications doing the same.

Here’s a 1993 essay by William Langewiesche from The Atlantic Online (sic!) that’s still on the web – which, by the way, you should read because it’s really great writing – juxtaposed with a screenshot of a 2026 Atlantic essay on the same machine:

Likewise, here is a BBC News article from 1997, and another one just from today:

I do see those as something different, though. The old articles here are basically preserved as they were, which you can tell by the tiny images, pixel fonts, narrow widths, and so on. They’re likely the output of contemporaneous CMS frozen in time, functionally equivalent to a “Save As…” command.

This is better than those articles disappearing altogether, and better still than them being carelessly converted in bulk to a more modern CMS, resulting in formatting mistakes, broken images, and missing context. But what I appreciated about Panic’s approach is that it felt unified with the rest of the blog. In a way, it was less like preservation “as is” and more like “remastering” – ask any Star Wars fan about the difference – with slight updates to fonts, more thorough integration, and thinking about readability on smartphones that didn’t exist in the 1990s.

Of course, compounding the difficulty of online preservation, “as is” in the computer realm doesn’t really exist; even The Atlantic Online’s 33-year-old HTML is served using modern fonts via crisp and tiny pixels 1993 would die for – but even if it’s increasingly more and more possible, you also probably wouldn’t want to emulate an old, flickering CRT and Internet Explorer 3 to read it. On the web, just like elsewhere in computing, you truly can’t go home again.

Thanks to Phil Gyford for a few examples.

Duff’s device is a C language technique that looks like this:

send(to, from, count) {
register n = (count + 7) / 8;
switch (count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
}

It achieves two things:

• It unrolls the loop in chunks of eight. Unrolling the loop is when instead of telling the computer “do X 5 times,” you say “do X do X do X do X do X,” trading some code readability and memory usage for higher speed.
• It cleverly (ab)uses a property of the C language to unroll the remainder of the loop, which normally would be impossible to do as the remainder is less than 8 and different every time. It does so by basically overlapping a do/while loop atop a switch/case structure in a way that should come with a coding equivalent of a parental warning.

I always assumed the technique is from the 1970s and was just a show-offy thing that didn’t serve any function, a “look how clever I am” from a programmer who was perhaps just a touch too nerdy. But yesterday, I found a 1988 message from the said programmer, Tom Duff, and it turns out I got almost everything wrong.

First of all, the technique was from 1983, when Duff was at Lucasfilm – much later than I expected.

Second of all, it actually solved a problem. Duff’s device wasn’t just making things faster abstractly, but actually fixed a user-visible performance issue. “[The loop before applying the device] was the bottleneck in a real-time animation playback program which ran too slowly by about 50%,” writes Duff.

Most importantly, however, Duff himself had mixed feelings about it:

Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this discovery.

I recognize this set of feelings from many different software hacks I invented in my life. I think it’s important to carry them all with you – not fall in love with the hack and continue seeing it for what it is (and what it will be in the future as code ages), but at the same time not be above using it if it’s solving a real issue.

Also, Duff adds:

Many people […] have said that the worst feature of C is that switches don’t break automatically before each case label. This code forms some sort of argument in that debate, but I’m not sure whether it’s for or against.

I can’t speak for C, but I have always felt frustrated about JavaScript stealing that convention – it’s so error-prone, and in my many years programming in it, I have never had to use a Duff’s device or anything else that benefitted from it.

On the most recent episode of The Talk Show podcast, this monologue from Jason Snell made me nod my head (the passage starts at 1:35:47):

[… Apple] decides to do a big feature. The circus comes to town, they build the feature, they launch it, they leave town, and that feature sits there.

And the problem is, there’s bugs, things are broken, and in Year Two, you’re like, “You’re going to fix all the things that were broken in the thing you shipped last year, right?” And in the last decade, I would say, a lot of times what happens is they just don’t. And if you’re lucky, they’ll fix it Year Three or Year Four, […] give it a polish.

The thing that troubles me most about Apple software quality in general is the feeling like they don’t have the people to own the thing that they launch. They build the thing that they launch, and then those people go off and do something else, and nobody is maintaining and improving the thing that’s there.

And whether it’s Time Machine, things that are often really system critical but that are super quirky, then they will do a brush up and you’ll be like “yay,” but… there’s still this bug, and then it’s “good luck, wait three more years.”

Or I think the one that we’re all thinking of this year is Screen Time, which they have a big revamp of. […] On one level, it’s great, but on another level, if you’ve talked to anybody who’s tried to use Screen Time, it’s broken. And so what they’re really doing here is trying to fix it, and we’ll see how they do. […]

The new features with problems is not a crime. It happens. The crime is: they never fix the problems.

And that’s the part that I would like to see Apple get better at: if you’re going to launch something, you got to maintain it. Sometimes I feel like Apple is willing to spend the money and time and effort to launch something, but then they’re not really willing to do anything other than walk away.

And I think that’s irresponsible. If you can’t stand by that feature, you shouldn’t launch it.

I think this is spot on, and said really well. Are you honest with yourself about resourcing and focus for right after the launch and then later on? Have you really thought about worst case and best case scenarios vis-à-vis bug reports, latency, user feedback, and craft/​quality however you define it? Have you actually started to make room for those outcomes ahead of time?

For me, an ongoing tension with Apple is Finder, so central to my (and I imagine many people’s?) use of a Mac, but rewritten at some point eons ago in a new framework that caused all sorts of problems, and then pretty much abandoned like a proverbial American city’s downtown. (I gave up listing stuff on this blog because it didn’t feel like fun, but I also see 100% of what Ilya Birman sees in his “Finder” section, many times every day.)

It’s not a story unique to Apple – I’ve seen many a designer and engineer quitting their jobs when an empty promise of a “fast follow” never materialized – but you’d expect them to do better here.

For a while, the digital artist James Dalzell Hodge kept a video diary of various design decisions while making his next game. This 13-minute video is interesting because it harks back to my mention of diegetic interfaces just a few days ago:

It’s a nice quick dive into the subject – a rare coverage of what “diegetic” means outside of the realm of movies.

I like these videos because Hodge focuses on details and shows working through things, including approaches rejected along the way. Inside, there are even occasional peeks at interfaces from Unreal Engine tools and Blender, not to mention examples from other games.

• A week of heads up before the payment happens
• The specific amount I’ll be charged shown
• Clarity about what is renewing and what I’m getting out of it
• Even a reminder about what Nova is, in case I stopped using it

Seems obvious, but so many places fail at some, and sometimes all of these.

I keep thinking about MacCharlie, this strange product from 1985 that turned the original Macintosh into a dual-purpose machine that could also run software by its chief competitor, early PCs:

I’m fascinated by it because it almost feels like cargo culting: “hey, PCs are big and ugly, so if we make a Mac big and ugly, it must turn into a PC.”

Of course, there was more method to this madness, and two alien cocoons wrapped around the Mac and its keyboard actually have the correct technology, but still – what an absolutely soul-sucking experience: an ugly on/off switch, ugly disk drives, ugly, slightly misaligned elements, ugly, ill-fitting, slightly off-color plastics, even ugly colors for key legends.

(Okay, I liked one thing – the embossed Dayna logo matching the Apple’s.)

This was not a novel idea. Those kinds of matryoshkas happened to computers before, and are still happening to computers today:

There even exists a concept of a “naked robotic core” – devices designed specifically to welcome more infrastructure around them. Here’s an example from the professional cine camera world…

…but your smartphone with MagSafe is gesturing toward this idea, too.

This is not limited to hardware, and it is in software where things get really interesting to me. Here’s a thing I saw the other day when installing some keyboard modification software:

The top is the native macOS interface. The bottom, including those arrow tendrils, comes from the interested app, trying to walk me through the process using some overlaid coach marks.

Or, this is something I saw on my Windows laptop. Putting aside none of this was what I gave consent for – again, top is native, bottom comes from McAfee:

Those adornments, whether “white hat” (like the keyboard tool), or “gray hat” (like the McAfee), all feel equally desperate and hopeful.

Desperate, because if this is the best idea, there are no good ideas. You can almost feel developers gritting their teeth, saying “I can’t believe we have to do this.”

Hopeful, because – well, you’re skating where you hope the puck will remain. At least the hardware, once mounted, cannot morph into something else. But the software appendage you create doesn’t really know how the host organism will evolve. Even a singular word change in the original UI can throw everything out of balance. This is no software proprioception where you control both sides of the equation and can re-synch them when either needs to evolve.

Okay, I imagine if you think ahead enough, and have an appropriately vivid imagination, and a robust QA process set up so you can react immediately when the host changes its UI from under you, you might get something passable.

But I think it will be hard. Sure, McAfee’s pop-up didn’t even try so its approximation of the “Enable extension” button is basically laughable – but CustomShortcuts did, and even then, the rounded corners and the shadows don’t quite match.

I think this is the foundational disadvantage of this kind of an approach. I imagine there are much worse and more nefarious “black hat” examples than the McAfee callout I showed above, but even without that, shoddy facsimiles of things are all around us – fake text messages from fake support centers, fake smartphone pop-ups telling you to update your OS – and we learn not to trust them. And this kind of UI inevitably starts as a shoddy facsimile. You can pull it, with effort, to be something better, but it will never forget its roots.

Here’s another “white hat” example:

This is from Raindrop. Again, you can sense some pretty understandable desperation as presumably iOS doesn’t allow you to add the highlighting and annotating commands to its top toolbar – hence additional, bottom toolbar.

I consider Raindrop a generally well-made app, but you can immediately feel a certain maccharlieness of it all here – what was mismatched plastics in the 1985 is mismatched liquid glass effects in 2026.

And, on top of all that, once in a while, disaster strikes:

This is what happens when you go to the homepage of Gemini and start typing quickly:

Mechanically, I think this is React or some other framework setting focus again with some delay, but the end result is… rather disturbing.

While the technical solution would be to fix the problem or at least do not set focus again if already set, I wonder what’s the real challenge here. I imagine it might be that the testing process (if any) assumes using the mouse or trackpad first. In this case, moving the hand to the keyboard to start typing gives the interaction just enough delay to miss the second, unnecessary focus.

I think a good assumption to have for all common interactions is that for some users, fingers are already on the keyboard and things can happen so much faster than you expect.

Not accounting for that, the creators of this flow inadvertently broke one of the cardinal rules. We talked about it in the context of mouse pointers before, but it applies as well to text: don’t move my cursor for me.

Since we’re talking about pixel art, in this 30-minute video, Stuart Brown known as Ahoy embarks on recreating an illustration called Four-Byte Burger:

The original picture was created by artist Jack Haeger on an influential computer Commodore Amiga in 1985, on prototype software that “was in such an early stage of development that it lacked a save feature, entirely.” Proper to-disk screenshotting didn’t come to computers until the 1990s, so the only reproduction of the picture was a photograph taken off of the display and reproduced in print in a manual for the graphics software; the original image pixels evaporated when the computer was eventually turned off.

Brown recreates the image using more modern means (Photoshop), but eventually goes back to an Amiga to try to display it as close to the original as possible. It’s a soothing watch, and there are some fun moments in the video, like rotating the CRT to “portrait mode” – in a world populated by smartphones, in some sense the image aspect ratio seems oddly prescient.

(Also, if you ever find yourself having to rotate a CRT, you can just degauss it instead of waiting all night. Degaussing a monitor is one of the forgotten weird tactile pleasures bordering on dark magic, and if you’re ever near an old CRT, ask someone to show you.)

The videogame MainFrames was released on Steam and Nintendo Switch in 2025 to positive reviews:

MainFrames invites you to meet Floppy and to browse a clever and charming platformer that plays out entirely within the windows and desktop of a PC monitor. You won’t want to press the escape key on this cozy outing!

Recently, I stumbled upon the artist Alexis Morille who worked on a game sharing a few visuals and animations on Bluesky.

Here’s what really happens under the hood when you resize the window:

And here are the other “UI daemons” helping you scroll the contents:

I believe the word “gremlins,”x before being usurped by the 1984 horror comedy, was generally used to denote little mischevious creatures that live inside machinery and cause trouble. I wonder what the word would be for the little creatures that do all the hard work.

I haven’t tried the game yet, but I found these to be delightful.

Before I say anything, I’d recommend you just visit the site of a new little app called Liquid Radius, click around, and see how you feel (don’t install it, though!):

So. One of the design memes surrounding macOS 26 Tahoe from last year – the one with Liquid Glass – was this screenshotted quagmire of mismatched rounded corners:

The tool, Liquid Radius, promises a solution, and then goes to strange lengths to accomplish it.

Fixing the mismatched radii is, apparently, much harder than for example something like Lickable Menu Bar, which many of you have spotted me using via various Unsung screenshots. To get Liquid Radius to work, you have to take a pickaxe to deep recesses of your operating system in order to disable some of Apple’s protective measures – stuff like FileVault (which you have to turn off momentarily) and System Integrity Protection (which you are never allowed to turn back on). The installation requires friendliness with command line and a stomach for multiple reboots, including some of a kind you might have never actually done before.

Then, there’s the website you’ve just seen: elaborate, with nice “before and after” animations, and a fun landing page. I thought the installation steps, given the complexity of the effort, were exemplary and even educational. There’s also a page listing all the apps confirmed to work, and a “How Liquid Radius limits its blast radius” (ha) section, revealing the author is clear-eyed about their work being a hack, and even the dimensionality of its hackiness. Even within the tool there are nice design details.

But, as I was exploring the site, I kept switching between “this is ridiculous!” (laudatory) and “this is ridiculous!” (derogatory) in my head.

At some point it all started feeling like… overkill. Is this really worth all this effort? Are there people who pay for and install this, lowering their system’s overall security and installing unknown code by unnamed developers? Do the ends justify the means? How much do rounded corners matter?

I’ve also seen many products that were a lot more complex, but came with smaller landing pages and fewer snappy taglines. At some point I even had this thought that if you wanted to make The Onion-style joke describing how designers can get incredibly self-serious and obsessed about some teensy detail, the site is exactly what you would do. You’d just never build the actual app.

(Caveat: I didn’t buy or install Liquid Radius for reasons that are probably obvious – nor would I recommend you do so – so I cannot fully discount this actually being an incredibly sophisticated practical joke.)

Maybe it’s my reaction to rounded corners in particular being its own exhausting thing in the design world – a shiny, shallow distraction of product designers in lieu of focusing on more important issues of utility, ethics, privacy, and so on. Maybe it’s the fact I’ve always been suspicious of the oft-told Steve Jobs round rect story: sure, round rects are everywhere in the world, but then so are regular straight corners. Or maybe it’s my own frustration that conversations about macOS and Liquid Glass still feel largely surface-level, on terms established by Apple at WWDC last year.

Speaking of this: timing-wise, Liquid Radius is peculiar, too. This effort was only launched in May, and graduated to 1.0 on the first day of WWDC, the same moment Apple announced they will fix this problem in the upcoming macOS Golden Gate – to audience’s applause – which renders Liquid Radius obsolete, and was an absolutely predictable outcome.

The Liquid Radius creator seemed perhaps surprised by it, and promised to keep the tool running, allowing people to continue customizing their border radii even after Golden Gate makes them all match – but that makes the product an even trickier proposition given the frightening installation steps and the very notion of anonymous, closed-source code being allowed straight into your system’s bloodstream. Besides, if you judge the tool on its own, visual-design terms…

…I don’t think you can simply straighten the corners like they’re showing in the bottom row without rebalancing it with other design changes I’m not sure the tool can make en masse for all the apps.

I know this is navel-gazing, so I will stop. I linked to some third-party fixes before, but this one is newly fascinating. I’m sharing this in part because I don’t know how to feel about it. It reminded me of the mixed feelings I had after watching Jiro Dreams Of Sushi: is Jiro a hero or a villain of this story? I couldn’t say then, and I still don’t know today.

It has been an interesting few weeks to ponder the relationship of style and substance. macOS Golden Gate announcements made me wonder: if you strip Liquid Glass of a lot of its original style via all the reactionary fixes, is what remains even worth the name? The controversial Ferrari Luce reveal not long ago was another rich entry point, especially as for Ferrari the style is a large part of substance.

I’d be curious how Liquid Radius feels to you.

When taking screenshots, macOS at some point followed iOS and introduced a “floating thumbnail,” which serves as a proxy of the screenshot you just took – you can drag it somewhere, open it to annotate, etc.

The thumbnail is a nice gesture. The problem is that I rarely do the things it enables, so the thumbnail is now an extra thing to deal with and dismiss. And you have to dismiss it, because inexplicably on macOS the floating thumbnail is diegetic, meaning it itself can be screenshotted. And this happens, routinely, if you do a few screenshots quickly in a row – the screenshotting tool literally ruining your screenshots. “You had one job,” &c.

(“Diegetic” is perhaps my favourite pretentious word. It generally stands for “in-universe.” If characters in a movie are listening to the song, that song is diegetic. If the song is just for the viewer as part of the soundtrack, that song is non-diegetic.)

You can turn off the thumbnail, but then outside of the sound – which is unreliable for other reasons – there is nothing else to tell you the screenshot was taken. And I think it’s good to have some sort of a confirmation, especially since the screenshot shortcuts are so harrowing.

Now, on Windows, when you press the equivalent (Windows key + PrtSc key), this happens:

I think this is better. It’s elegant, unmistakably recognizable as a screenshot, gone immediately, and a cute skeuomorphic nod towards old cameras.

In response to my recent interactive essay about interactions, Waider on Mastodon posted a great crystallization of a common problem:

There is nothing quite so frustrating as a persistent user interface papercut. You know it’s there, but you keep running into it because the moment you start thinking about what you’re doing instead of how you’re doing it, that knowledge slides away until BAM you run into it again.

I think this is really nicely put and highlights about why it’s very important to care about this kind of stuff.

If you forgo a standard interaction out of carelessness, a bug, bad systems thinking, or for other reasons, you’re not just making your users frustrated by something not working. You’re also at risk of making them frustrated at themselves, assuming they can change what their fingers do easily, not fully knowing that a) this is motor memory, not just regular conscious actions (and any memory is hard to “update” intentionally), and b) motor memory is separated from regular, declarative memory, and not possible to reason with using the same techniques.

(As an example, it’s very hard when keyboard shortcuts or mouse gestures disagree between apps, because while you consciously might know which app you’re in, that’s not necessarily true of your fingers.)

Waider continues with an example:

The canonical example of this, for me, is Microsoft apps on macOS: even now, decades after Microsoft started producing macOS versions of their apps, they insist on largely disregarding the native UI idioms in favour of their own. Current pet hate is that if I’m commenting on a document, the Ctrl-A/Ctrl-E actions do not work, and boy howdy do I use those constantly.

My recent example is that even though I wrote about Safari overriding the natural “scroll to top/bottom” tap gesture on their tabs – so I am aware of it in my declarative memory, I know Safari designers messed it up, and I know exactly what to do and not do – my fingers still occasionally tap to scroll in Safari anyway.

From Brad Woods, a messy (in a good way) and copiously illustrated/​animated exploration of “juice,” or:

Our wet little term for constant and bountiful user feedback. A juicy game element will bounce and wiggle and squirt and make a little noise when you touch it. A juicy game feels alive and responds to everything you do - tons of cascading action and response for minimal user input. It makes the player feel powerful and in control of the world, and it coaches them through the rules of the game by constantly letting them know on a per-interaction basis how they are doing.”

It’s mostly, but not exclusively videogame related, but it has some obvious tentacles reaching into the consumer and even professional UX world – at this point in Unsung’s history you all probably know I see these worlds as overlapping, hence linking to a lot of videogame interaction stuff.

Won’t be a surprise that I particularly liked the “level of juice” slider:

The whole page is messy, but that’s actually kind of great. It generously links to other things, too. I don’t agree with all the examples, but I the entire effort feels like it came from a person, and I really treasure that.

I also thought this notion was very clever:

There is a trend to juice rare events in non-game software. For example, an explosion of confetti to celebrate completing onboarding or a funny animated 404 page. Game developers do the opposite. They focus on the mundane, routine tasks. Because these are the foundation the rest of the software sits on.

(Brad Woods’s “Digital Garden” is generally worth checking out as a whole.)

A funny and occasionally spicy 15-minute video by Nerrel from October 2024 about some of the nuances and legal fights surrounding Nintendo’s fight with community-made emulators:

The video paints Nintendo in the harsh light, highlighting their double standards and willingness to throw their corporate legal weight around just to squash the challenges before they go to court, despite court precedents ruling against them.

The video also talks about software preservation – this is the part that feels very important to me – and I also learned things about piracy, DCMA, and modern video game encryption.

Just to highlight the versatile value of emulation, in another corner of the emulation universe, I found this fascinating project: a web page called Yes we scan, made by George MacKerron, that promises scanning directly from the browser – for example if you have an old scanner unsupported by your modern OS.

And… it actually works! It combines WebUSB with an interesting technique:

Your web browser emulates a whole PC running Linux with open-source scanning software (SANE). It connects that to your scanner via WebUSB.

If you are interested, the details page has more… well, details. MacKerron also wrote Printervertion that allows you to print directly from web, too, even if your operating system abandoned your vintage printer. The way I understand this, both efforts basically invite an alternative operating system that might be more supportive to take a stab at scanning or printing, and do it in a friendly and sleek way through emulation. It’s kind of incredible this is even possible.

Aanand Prasad, Ben Firshman, Carl Tashian, and Eva Parish put together Command Line Interface Guidelines for people who write command-line tools.

I like that it harkens and links back to other writing, and is also pragmatic: shares good parameter-parsing libraries, commonly used options, and so on.

Here are some good principles that caught my attention:

Display output on success, but keep it brief. Traditionally, when nothing is wrong, UNIX commands display no output to the user. This makes sense when they’re being used in scripts, but can make commands appear to be hanging or broken when used by humans. For example, cp will not print anything, even if it takes a long time.

It’s rare that printing nothing at all is the best default behavior, but it’s usually best to err on the side of less.

By default, don’t output information that’s only understandable by the creators of the software. If a piece of output serves only to help you (the developer) understand what your software is doing, it almost certainly shouldn’t be displayed to normal users by default—only in verbose mode.

Catch errors and rewrite them for humans. If you’re expecting an error to happen, catch it and rewrite the error message to be useful. Think of it like a conversation, where the user has done something wrong and the program is guiding them in the right direction. Example: “Can’t write to file.txt. You might need to make it writable by running ‘chmod +w file.txt’.”

Signal-to-noise ratio is crucial. The more irrelevant output you produce, the longer it’s going to take the user to figure out what they did wrong. If your program produces multiple errors of the same type, consider grouping them under a single explanatory header instead of printing many similar-looking lines.

Consider where the user will look first. Put the most important information at the end of the output. The eye will be drawn to red text, so use it intentionally and sparingly.

Make it recoverable. If the program fails for some transient reason (e.g. the internet connection went down), you should be able to hit <up> and <enter> and it should pick up from where it left off.

There’s a lot more inside.

(The document is undated, but I believe the effort started in 2020. It seems to still be updated via GitHub, where you can also send in your suggestions.)

Every once in a while, I stumble upon a long thread in a random corner of the internet where someone discovers Paste And Match Style, and everyone erupts in applause. “Yeah, it’s a life saver.” “I use it all the time.”“I can’t believe this isn’t the default!”

Then, inevitably someone chimes in: “Oh yeah? I can show you how to make it the default.” And they explain how to wire ⌘V to use Paste And Match Style.

And I always get worried seeing that.

I believe this is the core problem people are bothered by before discovering PAMS – when you copy and paste from another doc, you inherit its style/​visual appearance:

And Paste And Match Style, well, does what it promises:

This feels nice. So, what’s the problem? The problem is that PAMS is drunk with power and flattens everything on its way:

That includes:

• emphasis by italics or bolding
• links
• bulleted and numbered lists
• strike-through text
• headlines

None of these are “style.” This is actual information that should not be removed. If you wire PAMS as your main ⌘V shortcut, or even if you use it occasionally, you might remove valuable data from text you’re moving around, without even noticing.

(And if you do notice, the frustrating irony is that recreating the information lost in transit – for example, re-linking things one by one – is often more work than fixing the style would be.)

If you are designing an app that handles rich text, here’s what I have seen others do:

• Do not have styles to begin with. If you use Notion, Dropbox Paper, Medium, or anything that relies on Markdown, they give you no way to customize fonts, colors, letter spacing, and so on, so regular superliteral Paste has a limited blast radius and works well:

• Have a very strong center of gravity toward the default style. Apple Notes does this well. Use Notes for years, paste into it from all over the world, and you might never realize it allows you to change fonts and colors. Its default Paste removes style, but it doesn’t remove any valuable information like links or bullet points.
• Notes also introduces a shortcutless Paste And Retain Style as a third option after a “semantic” paste (which keeps data and removes style) and PAMS (which removes everything), for those who really want to paste extremely literally:

• Word has Paste And Match Formatting that seems to be what Notes does by default, but it’s not the default:

• Help users understand the options they have more. For example, Word offers a little post-paste menu. I don’t personally love (it doesn’t have a preview + it doesn’t remember my preference + the options are scary), but it uses better-than-default language like Keep Text Only, and it protects people from the harrowing backrooms of its own Paste Special:

• Have some contextual rules – for example Figma does things differently depending on whether you paste into a new text box (preserve style), or a text box that’s already filled (match formatting).

(If you’re seeing some other apps doing something interesting, please let me know!)

Doing the right thing won’t be easy. Books have been written about the illusion of the difference between “stylistic” and “semantic.” People use bolding for either. Others treat headlines as visual style, right aligning means something different in English than it does in Arabic, you might still have to normalize indentations, and so on.

But I believe it’s necessary to put in the effort to make regular Paste work as well as humanly possible, rather than relying on people to know about the far-from-perfect ticking time bomb that is PAMS.