Request for improved documentation of scope of Entry URI formats

[watershed]

The docs on Entry URI formats are helpful but I feel they could be more so.

I realise that this bit:

You can use an attribute from a query in the entry’s URI. Use double curly braces (e.g. {{craft.entries().section('mySingle').one().slug}}/news).

…in principle means that anything is possible – I can query anything right!? – and one can't document everything anyone might want to do!

However, I feel that this set of possibilities warrants a bit more prominence, and maybe a bit of fleshing out to make clearer the kinds of possibilities and some seemingly undocumented scope.

For example, here is what I've discovered today.

---

I have a 2-level Structure in which there's a slug schema of:

level 1: slug = thing
    level 2: slug = thing-topic

And I don't want a URL schema of /thing/thing-topic because now thing is present in the URL twice, and I would prefer thing/topic. But how to achieve that?

Can I use |replace in the URI format to get rid of thing-? I don't know.

I decided to use a category group to define topic slugs (devoid of their thing context), and a topic entry field to assign it.

I noticed the bit in the docs about parent.uri so I guessed that maybe I could reference entry.topic in the URI format:

{% if level == 1 %}{slug}{% else %}{parent.slug}/{entry.topic.one().slug}{% endif %}

…but that didn't work. So as a wild guess I tried leaving the reference to entry out:

{% if level == 1 %}{slug}{% else %}{parent.slug}/{topic.one().slug}{% endif %}

…and that did work. Hurray!

But how could I know that entry in this context is redundant?

---

I’m not suggesting this is a good example, but I describe it to highlight how guessing and messing around is not a great way to discover what is and isn't possible.

I don't know if that's addressable, but maybe it is?

Thanks for an insanely flexible app though :)

[watershed]

Doh! I just saw this bit in the Docs:

The entry being saved will be available to the template as a variable named object, and each of the entry’s properties and custom field values will also be available as their own variables. So something like this is possible:
{{ author.username }}/{{ slug }}

So this is probably just a case of me not reading the Docs adequately [facepalm], coupled with a bit of ‘sea of text’ syndrome.

But there is still a bit of confusion around single vs double curly braces. Is it perhaps that {slug} is a deprecated legacy thing and {{ slug }} is better?