ryan

or should I sanitize earlier at the $input->post->list?

I think it's probably just whatever you find most useful in your situation. But my preference is usually to sanitize on first access, unless I potentially need an unsanitized version to determine how it should be sanitized (which might be the case here).

The $value is tricky because it could be an integer or it could be the string "root". Maybe use an if on this one?

You could sanitize first with pageName (which sanitizes to [-_.a-z0-9], and then use ctype_digit to determine if it's an integer or string:

$value = $sanitizer->pageName($input->post->something); 
if(ctype_digit("$value")) {
  // it's an integer
  $value = (int) $value; 
} else {
  // it's a string
}

Name is a consistent term used throughout ProcessWire and also the term used at the API level, so I'm not sure it's necessary a good idea to change it (or at least it might be confusing). But I'm guessing it could be done by way of a hook after ProcessPageEdit::buildForm:

public function hookBuildForm($event) {
  if($event->object->getPage()->template != 'user') return;
  $form = $event->return; 
  $field = $form->get('_pw_page_name'); 
  $field->label = 'Username';
}

As for "page name in address bar", I don't think that we ever actually use the the name in the address bar for users since there is no /site/templates/user.php by default. So I'm confused on that one.

If you've got a situation where you are having to do something repetitive (like the image selection and placement you've mentioned), then look at breaking it down further. Images manually positioned in copy (via TinyMCE) aren't ideal, and are better for one-off or unique situations. It's better to standardize on dedicating a specific image field (i.e. featured_image) to be a method of automatically connecting an image with a page. There are also situations where you may find it helpful to associate images with page references. For instance, a blog post with categories might have the categories each have an image that gets automatically pulled in and displayed when the blog post is rendered. 

If I understand it correctly, it looks alright to me. We've done things like this before, connecting the user name with another page though rather than having a saperate "username" field, we just used the existing page "name" field to connect with the username. So that's the only thing I'd say, is to double check that you really need an extra "username" field, or if you can make use of the built-in name field to do all this. 

I'm not sure I understand this case. The error you are getting is what I'd expect if the LanguageSupportPageNames module wasn't installed. But since it is installed, it's a bit of a mystery there. I'll see what I can do in trying to reproduce it. But you do have an alternative to the localUrl() function, and that is to just set the user's language for each iteration of your $languages loop, and then call $page->url:

$saved = $user->language; // save user's language
foreach($languages as $language) {
  if(!$page->viewable($language)) continue;
  $class = "$language" == "$saved" ? " class='active'" : '';
  $user->language = $language; 
  echo "<li$class><a href='$page->url'>$language->title</a></li>";
}
$user->language = $saved; // restore user's language