Prefixing a folder with (.), (..), (..)(..) or (...) intercepts another route: during a client-side navigation the intercepting folder's page.js renders instead of the real one, while the address bar still changes to the real URL. Arrive at that URL any other way — typing it, reloading, a link from outside the app — and the real route renders. The dots count route segments, not folders.
The canonical use is a modal with a real URL. Three files serve /photo/7 in the demo: app/photo/[id]/page.js is the full page, app/@modal/(.)photo/[id]/page.js is the modal that wins on soft navigation, and app/@modal/default.js returns null. Clicking the gallery's link and then loading the same address directly gives two different documents:
click on the Photo 7 link from / -> URL http://localhost:3210/photo/7 <main><h1>Gallery</h1></main><dialog open=""><p>Photo 7 in a modal</p></dialog> hard load of /photo/7 <main><h1>Photo 7, full page</h1></main>
The gallery is still mounted behind the dialog, so closing it costs nothing: call router.back(), or link back to a route the slot does not match. That is what makes the pattern worth the folder gymnastics — the modal is shareable, survives a refresh as a real page, closes on Back and reopens on Forward.
Two traps. A soft navigation to a route the slot no longer matches leaves the old modal on screen, so most apps add an @modal/[...catchAll]/page.js that returns null. And because (.) counts route segments, photo is one segment up from inside @modal but two folders up on disk — which is why the folder is (.)photo and not (..)photo. Vercel 3,061 's nextgram sample (github.com/vercel-labs/nextgram (https://github.com/vercel-labs/nextgram 1,013 )) is a complete reference implementation.