Hi,
I'm not sure what do you propose.
If you are talking about
"an inbuilt method to process these tx" (in which software ? bitcoin-core ?) then there is
createrawtransaction which takes as parameter almost what you described.
If you are talking about kind of a script language that would compile to Script there is
Ivy but I have not tested it yet.
If I'm not mistaken OP is suggesting a method to reduce transaction size and therefore blockchain bloat.
So current tx. is (basically) like this right;
inputs;
(n times)
outputs;
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG (n times)
but this is really boilerplate. And probably like 90% of tx. are like this^. so why not have an inbuilt method to process these tx. much easier and more scalable?
I think one of the problems is that replacing boilerplate code like above with an abstraction makes it incredibly hard to upgrade the network when the logic behind the "simple_unlock" changes (or should change, due to a shift in usage of transaction formats).
Case in point -- the script used in the example above is already more or less obsolete, it's a legacy P2PKH transaction. Wrapped SegWit P2SH transactions already look different, native SegWit transactions look different still. All based on the same op_code primitives that every node understands (Well not quite, SegWit also saw the re-introduction of some formerly deprecated op_codes, but to be honest I'm not sure whether they are unrelated or necessary for these redeem scripts).
However I guess the main reason why we don't have a transaction type as suggested above is the lack of a viable ECDSA signature aggregation method. My understanding of cryptography is spotty at best though.