Interface / Contract usage and naming conventions

To caveat; I'm reasonably sure I now have the hang of Laravel's take on DI, including services providers, binding and contracts...

However, I have some questions regarding the (lack of) naming convention for contracts.

Even though they're just interfaces they're not named in accordance to interface naming conventions, i.e.:

• UploaderInterface
• IUploader
• iUploader

This has caused me more than a little confusion when trying to implement them in the DI manner! It's obvious what you're doing when you're simply implementing an interface in a class, as you're in the class, so there's no confusion:

public function SuperUploader implements Uploader
{
    public function upload() { ... }
}

What I've found does become confusing, when wiring and resolving bindings through type-hinting or App::make(), is mentally working out which class you're actually working with, and working out what imports to use, etc:

// service provider
$app->bind('Uploader', 'some\path\to\SuperUploader');

// some controller
public function upload(Uploader $uploader) 
{
    $uploader->upload(); // actually a SuperUploader instance
}

I know this is the whole POINT of contracts, but I'm constantly forgetting whether I'm working with a contract or a concrete class!

It just feels like yet more Laravel smoke and mirrors for the sake of it, when an explicit indication that you're working with an interface, not a class, would make things clearer:

// service provider
$app->bind('iUploader', 'some\path\to\SuperUploader');

// controller
public function upload(iUploader $uploader) { ... }

So I have 2 questions:

1. Why does Laravel not conform to the existing conventions around interface naming?
2. Does anyone have any tips or suggestion on how to get better at mentally managing all this invisible wiring?

Cheers,

Dave