[frowaway001]

  1) \ is usually taken for escapes, | is non-directional 
     and therefore doesn't work with arbitrary nesting, and 
     / causes the same problems as <.

     > Keep in mind Rust goal almost from the start was 
     > something that is familiar to a people that worked 
     > with Gecko engine. With that in mind, I can't think 
     > of a similar family language that did this.

     Isn't this the classic Golang emergency excuse?
     "Golang was built by Google engineers to solve Google's
     problems, so could you please kindly **** off, dear
     non-Googler."

     Nobody claims that <> isn't "familiar". People are claiming
     that <> isn't very good, and they are correct with that.
     Those languages which made <> "familiar" picked <> because
     they added templates/generics/... after the fact and tried
     to bolt them onto an existing language without breaking all
     existing code.

     <> was usually the least worst option for those languages.
     It doesn't follow that a language designed from scratch 
     should adopt <> without thinking, because there are better 
     alternatives when designing a language which has Generics 
     from day 1.

     > You know what happens when you call Index/IndexMut. 
     > To say it isn't so, is outright fallacious.

     extern crate rand;

     use std::ops::{Index,IndexMut};
     use rand::random;

     fn main() {
         let mut arr = MyFunnyArray { arr: [0,1,2] };
         println!("arr is {:?}", arr);
         arr[5] = 23;
         println!("arr is {:?}", arr);
     }

     #[derive(Debug)]
     struct MyFunnyArray {
         arr: [u32; 3]
     }

     impl Index<usize> for MyFunnyArray {
         type Output = u32;
         fn index<'a>(&self, _index: usize) -> &u32 {
             &self.arr[random::<usize>() % 3]
         }
     }

     impl IndexMut<usize> for MyFunnyArray {
         fn index_mut<'a>(&'a mut self, _index: usize) -> &'a mut u32 {
             self.arr[random::<usize>() % 3] = random();
             &mut self.arr[random::<usize>() % 3]
         }
     }

     Looks pretty arbitrary to me.

  2) > No we don't. I think having user and built-in 
     > defined types is perfectly ok.

     Sure, but how is this even related to the topic?

  4) > Related yes, same no. In same way i32 and u32 are 
     > related but not the same.

     As you might see, they are called i32 and u32, not i32
     and UnsignedInt4Bytes.
     
     > As I said in previous question having some subset of 
     > language be unable to modify is IMHO a good thing.

     I'm not sure what you are trying to argue here.
     Consistency has nothing to do with being "able/unable to 
     modify". People are unable to modify most types, it
     doesn't matter if they come from a third-party crate or
     the core language.

  6/7)
     > They can't. You can tell by mutability of array which 
     > one will be called and which one will be returned. 
     > You CAN'T EVER change type of mutability of result.

     Not sure what you suddenly try so say with "you can't
     modify this", "you can't mutate that".

     As shown in 1) [] can do whatever the developer implements.
     Sure, the usual language rules apply, I think nobody 
     disagreed on that.

  9) > Whenever I see macros/operator overload/syntax being 
     > given too much freedom, it always ends up with 
     > incomprehensible DSL-s that you can't disentangle from 
     > regular code.

     Yes, that's exactly the concern I'm raising here, because
     that's what Rust is encouraging.

 10) No, not really. Just compare the issues caused by using <> 
     vs. other approaches.