So we need a mechanism that is externally (i.e. from a class interface
point-of-view) a subroutine, but internally has the features of a method (i.e.
has an invocant). Since it's externally sub-like but internally method-like,
we call this useful construct a submethod.

For most of that, doesn't a private method suffice?
When it doesn't, I feel uneasy about:
class Foo {
submethod bar() { ... }
}
my $foo = Foo.new;
$foo.bar;
If that's externally sub-like, why does it look so much like a method?

Isn't looking like a method more a feature of the dot syntax than anything
else? Does bar($foo) cause the same perception? If my signature assumptions
above are correct then an argumentless bar call without "invocant" is a
"too few arguments" error.
If I understand the term 'package dispatch' of Sam Vilain correctly the
package that contains class Foo would maintain a dispatch into class scoped
subs depending on the immediate class---is that the eigenclass?---of the
"invocant". That is we could define
class Bar
{
has $.data; # creates rw accessor
our sub bar # sig is :( void: Bar $_, [EMAIL PROTECTED] )
{
$.data = 42;
}
}
in addition to the Foo from above and then
sub package_dispatched ($x) { $x.bar }
my $bar = Bar.new;
package_dispatched( $foo ); say $foo.data; # 23
package_dispatched( $bar ); say $bar.data; # 42
But I can understand that Damian thinks that spelling 'our sub' as
'submethod' is good documentation and not a subtlety. OTOH, a 'my sub'
is not considered too subtle. Actually a 'has sub foo ...' form might be
an alternate spelling for 'has &.foo = sub ...' and we can drop the
strange word 'submethod' and nicely unify all code types. That is
sub = package dispatch on void
method = unary dispatch on single invocant item type
multi = symmetric multi dispatch on invocant tuple type
or left biased successive single dispatch on invocant list
or a mix of both
--