If you scroll past the code examples, there are a few more details, though for more you'll need to look at the documentation (specifically
https://docs.inko-lang.org/manual/main/getting-started/memor...).
> Is `&T` a type?
Inko's syntax for references is `ref T` for immutable references/borrows, and `mut T` for mutable ones. Unlike Rust, you can't implement methods/traits _only_ for references, instead you can only implement them for the underlying "base" type. So `impl ToString for String { ... }` is valid, but `impl ToString for ref String { ... }` isn't.
> Can you store it in a structure, or return it?
Yes.
> Can you have a reference to a reference?
No, `ref ref T` is "collapsed" into just `ref T`, and the language has no notion of pointers and pointer-pointers.
> If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument
Inko doesn't have a borrow checker, so it doesn't. Instead it relies on runtime reference counting to prevent dropping of values that still have references to them. Over time I hope to implement more compile-time analysis to reduce this cost as much as possible, but borrow checking/lifetime analysis like Rust isn't something Inko will have.
Or to put it differently, I want the compiler to catch say 80-90% of the obvious "this ref outlives its pointee" errors without complicated borrow checkers. For the remaining 10-20% the runtime check should suffice.