current_path() shouldn't be used anymore. Instead, buildForm() should take Request $request as an additional parameter, and save that object to a property. Then here you can do $this->request->attributes->get('system_path').

(Note: Tim Plunkett may disagree with me here; there's some weirdness around forms and caching that limits their injectability at the moment.)

I have added entity manager but not sure if I need to remove this function -

$sets = entity_load_multiple('shortcut');

Also, not sure how to do this. Is there any example, I can follow or documentation will help.

current_path() shouldn't be used anymore. Instead, buildForm() should take Request $request as an additional parameter, and save that object to a property. Then here you can do $this->request->attributes->get('system_path').

Need some clarification on the following -$this->currentPath = $request->attributes->get('system_path');

There is no $request in this scope, so this line will fail.
For a controller, you never need the request in the constructor. Instead, you can get it passed into the controller method itself.

Looking at form interface api (submit form) it takes only two arguments and so not sure how can I pass request argument in the controller method. That's why I passed request argument in the constructor method.

Once that's in, the buildForm() method will work just like any other controller method. As long as parameters you add after the first two are nominally optional (ie, have a default defined), they still will pass the interface and will get parameters passed to them by name just like controllers, including the Request object.

I think this can be simplified. The administer marker can be moved to its own _permission check. Then this checker can just check "does this user have a permission AND is editing their own account" ? ALLOW : DENY.

Then we switch the access mode to ANY. That makes it a good example of how "admin override permissions" can work for other routes.

Oh yikes. That's right, $account is what we call the active account, not $_account. This is again seriously confusing. Honestly right now I don't even know which variable is which anymore in this patch, which is a bad sign. :-) All of these need better names.

For a mocked request for menu access checking, yes, we should pass the account down through. If that resolves that todo, great. If not, we should note in the todo what circumstances that would be, even if it's just a @see menu_item_route_access().

Are we actually doing this now? I know most other access checkers still do $request->attributes->get('_account'), I was thinking we'd start passing $account to access checkers when we want to phase out _account.

Are we actually doing this now? I know most other access checkers still do $request->attributes->get('_account'), I was thinking we'd start passing $account to access checkers when we want to phase out _account.

Whatever you think is the way to get this patch in.

#2073813: Add a UrlGenerator helper to FormBase and ControllerBase is close, keep that in mind. Also this should really be "The URL generator."

So let's not deal with injection then.

I don't even get these failures and for sure they pass locally as every good test.

I don't care ... all I did was to rerole the already RTBC patch :) I do agree that for every special case where it is not obvious _access is helpful.
Some examples where the behavior is obvious: _permission, _role.

So this is ALL, is it worth specifying for when the default switch happens?