Oops, typo. Fixed above. Thanks!

1. Your first suggestion adds a special case to the language. That the module name somehow refers to the impl. I don't see the benefit though.
   Unnamed impls are a possibility, but I'm still not convinced it's necessary or good.

2. Adding a method keyword is something we considered. But why is it better than the self keyword?

3. I don't see why genericless traits are a mistake. Are 0 size types a mistake? Are traits with no functions a mistake?

IMO adding edge cases to the language just because they don't seems to be used often, is a mistake. It makes it harder to understand the language and is an opening to inconsistencies (for example, when using macros to generate code).

A module is not the same as an impl at all! You can't pass it as a generic arg!

Also, genericless impls are useful. From the top of my head:
trait Graph{
fn neighbors(Node)->Array;
}

For am algorithm that is generic in that impl.

In rust you would make a wrapper type. In cairo you don't need.

1. Your first suggestion adds a special case to the language. That the module name somehow refers to the impl. I don't see the benefit though.
   Unnamed impls are a possibility, but I'm still not convinced it's necessary or good.

Sorry, that's not really what I meant. What I wanted to point out was that how impl are resolved lead to this working nicely. Because you can currently import a specific impl by importing the module containing it (per the rule of impl are resolved in the the current scope, in the trait scope and in the scope of each of the generic arguments. ).
So in essence nameless impl already work fine and have a de-facto name / grouping -> the name of the module. If you wanted to use modularAddition you'd just have a ModularAddition module somewhere containing all those impls, no need to import specifically the impls.
So it would look like

// math.cairo or something
trait Add {}
// ModularAddition.cairo
use math::Add;
impl Add { /* specific code for modular addition */ }
// usercode.cairo, bring the impl in scope via the module being brought in scope.
use corelib::math::ModularAddition;

(and to clarify in this example, the only difference from working Cairo1 code is that you'd need to write Impl _ of Add right now).

2. Adding a method keyword is something we considered. But why is it better than the self keyword?

Is the self keyword actually a keyword here or does it just take the type of the first variable ?
The reason is just the logical continuation of your reasoning I think:

This begs the question though, why is there an asymmetry between i32 and u8? Between left and right?

I agree that there's no real reason for this asymmetry in self-less traits, so why not make the method thing explicit. It would only be a keyword on the trait level which is perhaps not a ton of syntactic noise, and could enable nice use-cases such as commutative operators (as described for Add of two different types maybe).
It would also make explicit something that is currently implicit (defining a method), and that particular thing Cairo 1 is a bit 'weird' on, so maybe the added explicitness would be a good thing for e.g. new devs.

I get that in most cases you'll be defining methods on the first argument though, the self type, so this might be seen as a little redundant, but then you could just make the self a property of the trait in the first place and then have it be implicit.

Anyways, this isn't really a good or bad thing necessarily, just an interesting direction that this 'full symmetry' / self-less trait direction can be taken on.

A module is not the same as an impl at all! You can't pass it as a generic arg!

Sorry, my point was that a generic-less trait ends up being the same sort of 'thing' as a module, not that a module is the same thing as a trait in general.

3. I don't see why genericless traits are a mistake. Are 0 size types a mistake? Are traits with no functions a mistake?

Well, generic-less traits are kinda weird. They don't necessarily feel like a logical extension of 1-generic or n-generic traits, because they still define methods.
What I would expect from higher-generic-traits is that no-generic traits are just a bundle of functions, not a way to specify methods on some specific types. If you don't have a self type and no generic type argument, what are you defining methods on ? But in practice, 0-generic traits seem to correspond to struct implementations in rust, which use a slightly simpler syntax, and aren't a trait at all.
So that's kind of unexpected and IMO a little weird, which is why I think they could be removed.
Though in that case, with respect to this:

Also, genericless impls are useful. From the top of my head: trait Graph{ fn neighbors(Node)->Array; }

Isn't that just a struct implementation, which takes an impl in rust? Intuitively, I would side with rust that their behaviour makes more sense.

Consider rust:

struct Node {}
impl Node { fn neighbors(Node) -> Array; }

v Cairo

struct Node {}
trait Node { fn neighbors(Node) -> Array; }
impl NodeTrait for Node { fn neighbors(Node) -> Array { ... } }

But maybe I'm misunderstanding you or missing something, because I don't understand this comment:

For am algorithm that is generic in that impl.
In rust you would make a wrapper type. In cairo you don't need.

You mean an algorithm that would take an arbitrary 'Graph'-compatible type ? But Cairo 1 doesn't really allow that since the Graph trait is defined only for the Node struct?

After a talk with @spapinistarkware, here are the answers to the above:

1. Regarding naive nameless impl, this could lead to ambiguity that cannot be resolved. E.G. this is possible:

// moduleA.cairo
impl TryInto<felt252,u256> { ... }
impl Into<u256, felt252> { ... }
// moduleB.cairo
impl TryInto<felt252,u256> { ... }
impl Into<u256, felt252> { ... }
// Now you cannot import one from A and one from B, so in some cases this could get you stuck.

2. Is the self keyword actually a keyword here or does it just take the type of the first variable ?

It is indeed actually a keyword, so the rest of the comment doesn't really apply. Ergo, traits don't always define methods, and so things make more sense overall.

3. Part of the comment is invalidated by self being special. Shahar also said that a more rust-like syntax to declare methods on struct was possibly wanted, so that part of the comment may also be invalidated in the future.

With regards to the usefulness of generic-less traits, they can be seen as 'groups of functions' for generic programming.
E.G. you can have this:

trait MathOp {
 fn Add(...);
 fn Sub(...);
 fn Mul(...);
}
// I believe this isn't cairo 1 syntax for this but you get the idea.
// This function is only defined for these specific operations.
fn ProcessOp<op: MathOp>(a, b) {}

Instead of having to do something more like this:

struct MathOp;
trait MathOp {
 fn Add(...);
 fn Sub(...);
 fn Mul(...);
}
impl MathOp for Mathop {...}
fn ProcessOp<op: MathOp>(a, b) {}