Only if all of your validations are completely unique.

That isn't the point. If you want to call a common validation routine from the validation part of the subroutine, there is nothing to prevent that. The problem with tieing is that you loose all the contextual and ancillary information available from the call. Eg the parameters.

A general tie mechanism FETCH has none or one parameter. The STORE has one or two. Adapting the tie mechanism to provide access to the parameters to a general subroutine call--especially with all the variations of named, positional, slurpy & non-slurpy parameters that P6 allows--is simply impossible. How then to convey that information to the FETCH and STORE?

I don't understand how that (the pascal typing system) is relevant to the discussion at all

The example Pascal was intended to show that when trying to use the type system to validate parameters, it becomes necessary to create myriad individual types all slightly different. Once you have that, you then have to deal with the problem of trying to composite values together to form composite types.

The problem is not limited to Pascal's sucky type system, but to all type systems that attempt to use that typing system for value validation.

How do you define a type to validate a string only contains upper case chars? Or is less that 20 chars in length? Or is a prime number? Or a power of two? Or a number between 0 and 1?

How would you encapsulate the verification criteria for a list assignment where all the values must be:

1. unique (both within themselves and within the larger array to which they are being assigned through a slice operation).
2. Odd Even. (Updated to avoid the Odd implies non-zero sidebar).
3. Non-zero

How do you define that as a type?

Typing and validation are entirely different animals and attempting to use the former for the latter invites a huge mess.