"A gyakorlatban viszont a backup fájl visszaállítása után már eltűntek a kiegészítők az Extensions mappából."
Hát ez meglehetősen fura. Akkor ez valami új Opera-specifikus bug lehet, ha valóban így van, legalábbis ilyet én Chrome-nál még soha nem tapasztaltam kiegészítők kapcsán.

"Ez nem az a probléma. Csak az unpacked extensionoknál van Reload gomb."
Jaja, de azt hittem, arról beszélünk. De ha nem unpackedről beszélünk, akkor meg ott van a pipa kiszed-pipa visszarak módszer... Ugyanazt éred el vele.

"De a régi Operánál az alapfunkciók natívan voltak megcsinálva, így csak kb. 10%-ban kellett kiegészítőkre támaszkodni. Itt meg 100%-ban. Ez nem mindegy."
Ebben egyetértünk, ebben nem is volt vitánk eddig sem, sőt, ezt már sztem egyszer-kétszer részletesen ki is tárgyaltuk. Ettől még viszont a Chrome Extension API kialakítása, minősége, dokumentációjának minősége nagyon jó. Az másik kérdés, hogy bizonyos funkciók a Chrome-ban miért nem elérhetők inkább alapból IS (!), hogy ne kelljen kiegészítő hozzájuk. Meg miért nem lehet átszabni a Chrome felületét kicsit, miért nem lehet oldalra dokkolni a könyvjelzősávot, és hasonló alapvetően elvárható dolgok, amikről már beszélgettünk. Na de most nem az volt a téma.

"Oké, akkor mondom: Ha nekem van már két padding !important-os értékem a left-re és a right-ra, akkor egyben szeretném egyetlen (nem kettő, egy) érték átírásával módosítani.
Vagyis jelenjen meg, hogy padding: 5px, ami vonatkozik elviekben mind a 4-re, de csak annyi jelenik meg, hogy 5px.
Nem 5px 5px 5px 5px (amiből kettő át van húzva az !important-os felülbírálás miatt)."
Huhh, akkor még mindig elbeszélünk egymás mellett, sztem én sem értem, te mit szeretnél, és te sem érted, én mit mondok...
Tehát négyféleképpen is lehet megadni a paddinget, direkt más és más értékeket használok, hogy elkülöníthető legyen:
https://developer.mozilla.org/en-US/docs/Web/CSS/padding
padding: 5px;
mind a 4 oldalra fog vonatkozni az 5px
padding: 5px 10px;
fölül-alul 5px, bal-jobb oldalt 10px
padding: 5px 10px 20px;
fölül 5px, bal-jobb oldalt 10px, alul 20px
padding: 5px 10px 20px 30px;
fölül 5px, jobb oldalt 10px, alul 20px, bal oldalt 30px

Na, vegyük azt, hogy az utóbbi formában van megadva, hogy padding:5px 5px 5px 5px;, ekkor rámegyek a szerkesztésre, és szépen a fölül lévő paddingre ráállok a kurzorral, és elkezdem nyomogatni a felfelé vagy épp lefelé nyilakat, az alábbi képen például épp a felfelé nyílra nyomogatok, és csakis a fölső paddinget növeli:

Tök jól lehet csak a fölső paddinget növelni ebben a shorthand CSS property formában is, kényelmesen a nyilat nyomogatva. Mi ebben a nehéz, mi ezzel a probléma?

A belinkelt Operás képeden pontosan ugyanezt csinálod, csak úgy tűnik, nem fedezted fel, hogy ezt Chrome-ban is pontosan ugyanúgy meg lehet csinálni...

"Ott meg van olyan, hogy "Expand shorthands""
Ez viszont jogos, erről megfeledkeztem.

"Pont látszik, mivel így ha userCSS vagy kiegészítő módosított valamit is mutatja."
Na, akkor screenshotoljunk ismét.
Kérlek, mondd már meg, hogy Opera Dragonfly-ban mégis hol mutatja a Computed Styles részben azt, hogy pontosan az adott tulajdonság melyik fájlokból is származik:

Chrome:

Dragonfly:

"Pont Dragonfly-ban tudod külön-külön szerkeszteni pl. a paddingot, míg Chrome-ban kibonthatod, de nem felül tudod szerkeszteni csak. A kibontottra hiába kattintgat az ember."
Asszem ennél most értettem meg, mi a problémád. Beírom a Dragonfly-ba, hogy padding:5px 5px 5px 5px;, erre csinál nekem belőle egy padding:5px;-et. Milyen alapon? Ha meg az "Expand shorthands"-re megyek, akkor mindenhol kibontja. Ha kiszedem ebből a pipát, akkor visszaalakítja a túl rövid változatra. Hadd döntsem már el, hogy én milyen formában szeretném szerkeszteni, helyettem ne rövidítse le padding:5px-re. Nem kell ezzel persze egyetérteni, de pont te mondtad, hogy egy program ne akarjon okosabb lenni nálad, belekontárkodni abba, amit csinálsz, hát akkor ez mi, ha nem pontosan ez a viselkedés?!
Felülbírálja az akaratomat, menjen az anyjába, ne bírálgasson felül.
Szóval megint elég következetlen az érvelésed, mert egyszer azt mondod, hogy te akarsz mindent irányítani, most meg elégedett vagy azzal, hogy a Dragonfly helyetted okoskodik. Ez akkor hogy jön össze?

"Webfejlesztésnél biztos, userCSS-nél nem hiszem."
Nem tipikus, de miért ne fordulhatna elő, hogy meghatározol egy általánosabb stílust pl. bekezdésekre, és egy specifikusabb stílust is adott bekezdésekre az előzőeken felül, amit máris elkúr az imént meghatározott !important, vagy pedig ide is ki kell rakni az !important kulcsszót? Ez User CSS-nél pontosan ugyanúgy előfordulhat, mint webfejlesztésnél.

">>"egy szar, kényelmetlen megoldást választottak, hogy nekem manuálisan kelljen hozzáadnom egy attribútumot, jobb klikk, Add attribute, "style" bepötyögésének bénázásával"
Miért kéne ilyet csinálnod? Duplaklikk egy teljesen irreleváns, de az adott DIV-hez tartozó elembe, majd Enterrel csinálsz egy sortörést, az új sorba meg már azt írsz, amit akarsz."
Hát nem gondoltam, hogy még ezt is külön el kell magyarázni. Egyrészt: nem biztos, hogy lesz egyáltalán a stílusfájlokban olyan meghatározás, ami az adott divre vonatkozik. Vágod? Így hogyan fogod szerkeszteni? Csakis úgy, ahogy leírtam. Szépen kézzel kell bénán bepötyörészni a style attribútumot, hogy CSAK az adott elemre vonatkozzon.
Másrészt: mi van, ha én CSAK az adott elemre szeretném vonatkoztatni a stílusváltoztatásokat, nem pedig globálisan, minden hasonló divre?

Na, de hogy konkretizáljuk az első felvetést:
http://jsfiddle.net/72sKE/

No, tessék, itt kérlek a Dragonfly-ban mutasd meg, hogyan fogod csak az adott divre vonatkozó stílust módosítani azok nélkül a módszerek nélkül, amiket írtam (vonatkozó selector írása a New style résznél, vagy pedig a kézzel való style-attribútum hozzáadása). Előre válaszolok: nem fog menni.
De screenshot legyen megint:

Chrome:

Opera Dragonfly:

Hopsz, az Opera Dragonfly megint alulmaradt.

"Most próbáltam ki. Duplaklikk a DIV-en, megnyílik szerkesztésre egy <i></i>-vel körülzárt rész. A felső i-re duplaklikkelek, kijelölődik az i betű. Átírom p-re, majd nyomok egy Enter-t. Meglepő módon a zárótag is kicserélődött p-re."
Akkor kérlek itt írd át a <p>-t <div>-re:

Lehet, hogy valamit kihagytam, de hiába duplaklikkeltem a <p>-re, nekem következetesen csak a HTML-szerkesztés jött elő. Habár pont te említetted ezt korábban, mint előny, úgyhogy most nem tudom, miért érvelsz amellett, hogy jobb a Dragonfly, ha neked mégis sikerült duplaklikkre NEM azt a viselkedést előidézni, amit szeretsz.... (ismét ellentmondás, nemde?)

">>"Ja, tényleg, mielőtt megfeledkezem róla, a JSON-fájlok feldolgozása, írása gyorsabb, mint az INI-fájloké."
Az XML-é meg még gyorsabb."

Ezt mégis honnan veszed? Ez ilyen formában egészen biztos, hogy nem igaz. Erre is vonatkozik a sokszor előkerülő "attól függ"-szabály. Azért ilyen merész kijelentések előtt inkább végezz valami komoly tesztet az adott környezetre vonatkozóan, különben így sokat nem ér a kijelentés.
Egyébként nekem az a véleményem, hogy ilyen feladatra a JSON gyorsabb lehet, de mivel nem vagyok róla teljesen meggyőződve (nyilván van mindkét oldalra szóló felmérés ESETFÜGGŐEN, ahogy ez általában lenni szokott, sűrűn vitáznak az XML vs. JSON-ről), ezért inkább tartózkodom.
Mindenesetre számomra az extension API esetében kényelmesebb a JSON-formátum, örülök is neki, hogy ez a formátum lett a befutó.

Sk8erPeter